3 ms·

This looks really nice but the plan structure is very weird. Why do I need to know or care how many concurrent connections my querying or administration requir

This looks really nice but the plan structure is very weird. Why do I need to know or care how many concurrent connections my querying or administration requires? Is this to stop people having more than one tab open? Why can't you just use connection pooling and probably not exceed more than 2 or 3 regardless? The tiny limits on returned rows means many tasks are going to made tedious, simple stuff like pulling out every name/email subscribed to a mailing list is going to take multiple queries even on the pro plan.

sehrope 14y ago
As we scale up JackDB, we'll be bumping up the usage limits and revising our pricing plans. Connection pooling doesn't really make sense in this context because users can't share a database connection; if one is in the middle of a transaction, he could get clobbered by the other's work.
- benologist 14y ago
  Connection pooling usually happens at the driver level, basically when you 'close' a connection it doesn't typically close it just gets flagged as ready to be re-used so the next query doesn't suffer the full overhead of establishing the connection. Unless you're counting connections in some other way (or persisting them?) this means in the pro plan for instance I would need up to 20 literally-concurrent queries executing to actually use those connections at the same time which is really only applicable in a web-facing situation where you might have 10s or 100s or 1000s of concurrent users running queries. From a technical stance an entire team of people accessing the database may fit within the '2' connections of the most basic plan just because there's not enough people to trigger high enough concurrency to require additional connections. In an administration etc context it seems extremely unlikely unless I've got some long running queries which are also unlikely in a session/browser based service since the odds of closing before a query completes are too high. It would make much more sense to charge directly based on the number of people actually administrating the database. It would also be cool to see "plug your S3 credentials in" and have backups taken care of, this is something MongoHQ does and it's beautiful in its simplicity.

sehrope 14y ago

As we scale up JackDB, we'll be bumping up the usage limits and revising our pricing plans. Connection pooling doesn't really make sense in this context because users can't share a database connection; if one is in the middle of a transaction, he could get clobbered by the other's work.

benologist 14y ago
Connection pooling usually happens at the driver level, basically when you 'close' a connection it doesn't typically close it just gets flagged as ready to be re-used so the next query doesn't suffer the full overhead of establishing the connection. Unless you're counting connections in some other way (or persisting them?) this means in the pro plan for instance I would need up to 20 literally-concurrent queries executing to actually use those connections at the same time which is really only applicable in a web-facing situation where you might have 10s or 100s or 1000s of concurrent users running queries. From a technical stance an entire team of people accessing the database may fit within the '2' connections of the most basic plan just because there's not enough people to trigger high enough concurrency to require additional connections. In an administration etc context it seems extremely unlikely unless I've got some long running queries which are also unlikely in a session/browser based service since the odds of closing before a query completes are too high. It would make much more sense to charge directly based on the number of people actually administrating the database. It would also be cool to see "plug your S3 credentials in" and have backups taken care of, this is something MongoHQ does and it's beautiful in its simplicity.