The engineering blog of Compose, a managed database hosting company, with tutorials on PostgreSQL, MongoDB, Redis, and RabbitMQ.
HN commenters mention Compose mainly as a managed database provider, discussing its pricing, its later ownership by IBM, and its work-sample hiring process.
> secure and scalable
> over the Internet
What does this really mean? How does this substantially differ from the now-facetious term 'web scale' [1] ?
Modern RDBMS'es offer encrypted communications between client and server [2][3][4], but nothing is stopping a deployer from putting a proxy between the database and the Internet-resident end-user to translate between authentication mechanisms. In fact, this happens in every single API today, where the Basic or OAuth or Cookie-Auth request comes in the HTTP body, and gets made into a database query in a query language the DB understands -- SQL or something else.
GraphQL needs to you bring your own authn/z [5][6][7] much the same way that your run-of-the-mill HTTP API needs to you to bring your own authn/z, so I can't accept 'secure' as an innovation over SQL. "Scalable?" How?
I genuinely think this tech is neat but let's consider what it gives you. GraphQL packages together the query language known as GraphQL, the IDL/typespec language known as GraphQL, the server spec known as GraphQL which a GraphQL-compliant server must implement [8], inside which you have to hook up your actual datastore to the GraphQL server [9][10][11][12]. It's a useful tool to build a client-server system where you're going to make a backend query in the end, but I wonder if its full potential will be realized when there are GraphQL-capable datastores to skip that extra data munging layer you have to implement yourself; but if SQL were passed on…
Compose | Remote (Canada, US, UK - Please see website for specific locations)
What: Databases-as-a-service. We offer production grade, auto-scaling, automatically backed-up, add-on compatible MongoDB, PostgreSQL, Redis, and more.
Hiring Process: Blind hiring! First, a light application. Second, all candidates who complete the application receive a work-sample resembling the work one would do in the role. No deadline. Final step is a work day.
Compose has grown into a vibrant group where folks can feel comfortable being themselves, living a balanced life. We welcome you to enjoy comfort when taking risks, collaborate with spirited peers, and to unleash your creative and talented personality.
* Work from home!
* Many neat conundrums to solve.
* Self-managing, distributed decision making. Choose your projects. We're deadline averse and quality focused.
* Hardly any meetings.
* Ruby/Go.
* Fizz: https://www.compose.com/articles/the-tool-we-built-to-help-us-work-remotely/
Roles:
* Database Team Member
* Support Engineer
* Visual Designer
* Marketing Growth Specialist
To begin: https://compose.interviewed.com
If the data would be considered the customer's, it would have made sense to use application-level encryption [1]. Each user has a unique key which should be their property. If you need to give access to that data without the user's consent, you'll need to store their unique key for them. You'll better do that in a very secure manner.
If now somehow the database gets exposed, good luck! You'll also need to get the individual keys to decipher everything.
Then, although still you can be blamed for not using a vulnerability scanner, there is much less at stake.
[1] https://www.compose.com/articles/encrypting-sensitive-data-in-your-mongodb-database/
^or the other IBM company whose name I can't remember
I think you are referring to Compose[1].
We differ with/from the alternatives in a number of ways:
- We have No rate limits. We do not limit the number of messages you can queue, the number of queues or any other artificial else.
- All our plans are on dedicated server. We do not setup shared RabbitMQ servers(vhosts).
- We do support HiPE (High performance Erlang).
We have a comparison page[2] where we list more of these differences.
1. https://www.compose.com/databases/rabbitmq
2. https://www.amqphosting.com/us-vs-them
Thanks for the link to Pgbouncer, I'll check that.
I'm using Cloudflare Workers which are distributed on the CF network and run at the edge to reduce latency. Achieving the same thing with containers would be probably complicated and expensive.
Right now I'm using Fauna DB which is also distributed and doesn't have connection limits, but I want to explore all my options.
Edit:
If anyone wants to know more about PGBouncer and pooling with postgres I found this article very informative:
https://www.compose.com/articles/how-to-pool-postgresql-connections-with-pgbouncer/
My company does managed Postgres on AWS, Azure, Google Cloud Platform, DigitalOcean and UpCloud - https://aiven.io/postgresql. Compose offers managed Postgres (https://www.compose.com/postgresql), as does ElephantSQL (https://www.elephantsql.com/). Database Labs is one more provider (https://www.databaselabs.io/).
Google recently added beta version of Postgres to Cloud SQL as well (https://cloud.google.com/sql/docs/postgres/). Of course, AWS RDS and Heroku have been on the market for some time.
I'd claim managed Postgres market is in a pretty good shape.