3 ms·

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 becaus

• 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.