5 ms·

Just don't use a single Postgres DB for everything as you scale up to 100+ engineers. You'll inevitably get database-as-the-API. Now if you have the actual tec

• RedShift1 2y ago
  > You'll inevitably get database-as-the-API I think that's actually the point of "postgres for everything"?
  • whateveracct 2y ago
    If you don't have any discipline it becomes hell. Not to mention that a random team writing a migration that locks a key shared table (or otherwise chokes resources) now causes outages for everyone.
    • blackenedgem 2y ago
      Right but in this "100-engineer" scenario you'd have hoped the following would have happened: - Docs and guidelines on migrations would have been written - Some level of approval and review is required before execution These are things that isn't really postgres specific, any company that doesn't have those is going to be a nightmare.
      • robertlagrant 2y ago
        If teams have technical boundaries defined at a higher level in the stack (e.g. APIs) and so they don't share a database, you don't need loads of process and docs and architectural meetings to coordinate. Letting teams delivery independently is a good architectural feature.
        • ForHackernews 2y ago
          This is why everyone adopted "microservices" - it's Conway's law in action, a technical intervention for an organizational problem.
      • whateveracct 2y ago
        Even with those things, blast radius for mistakes is ..the entire company is down. e.g. User management deploy has somehow taken down core payment processing.
    • xnx 2y ago
      Not a problem until it's a problem.
      • com 2y ago
        And the best thing is that until it’s a problem you can focus on product/market fit and delighting your customers. Overengineering is a plague amongst SWEs, and almost as dangerous as failing to sell the product in the market.
        • whateveracct 2y ago
          I think cargo cutting stuff like "Postgres for everything" is also a plague. I agree you don't want to overengineer, but if you're a leader and your policy is basically "engineers can't ever be trusted to do hard things" then you're a bad leader. Sorry if this comes off as brusque, but I've seen good engineers want to use Elasticache for the right reasons and seen "leaders" tell them no because "caching is one of the hard problems in computer science." Leadership-by-folksy-saying is sadly a real thing.
          • com 2y ago
            I worked in a Postgres for everything business, and the IPO and later value creation for customers and investors (including me) had been stratospheric. Not dealing with loads of technology choices in the early days is a boon. Once we hit more than $100m in rev it made sense to allow a bit more optimisation for purpose - but only when we had cash flow to pay for it. Otherwise all these fancy-shmancy choices are just dressed-up tech debt.
            • whateveracct 2y ago
              > Once we hit more than $100m in rev Yeah my original comment was about experiences working at places with this kind of monetary success (if not more) and stubbornly not evolving. Low trust eng leadership philosophies will do that though.
      • pdimitar 2y ago
• underdeserver 2y ago
  Drop the scare quotes from "successful". These guys shipped products. The migration to multiple databases, syncing user information etc. is a milestone, not a necessity at every step.
  • szundi 2y ago
    Thank you
  • devjab 2y ago
    Unfortunately a lot of places teach software engineers to build over complexity before they need it. I like to remind people that StackOverflow ran on a couple of IIS servers and a msSQL db for a good while before scaling up to a little more than a couple of IIS servers. Hell they didn’t even do the CDN thing until 2017 or something similarity “crazy”. Mean while you have hordes of developers who write interfaces which will only ever be consumed by a single class because they’ve been taught to do so. As I see it the only way to look at scaling issues is that you’ve made it. Almost no user facing software will ever reach a point where something like Django couldn’t run it perfectly fine. It’s when you do, you build solutions, which sometimes means forking and beating the hell out of Django (Instagram), sometimes going into Java or whatever, spreading out to multiple data bases and so on. Of course once you actually hit the scaling issues you’ll also have enough engineers to actually do it.
    • jumping_frog 2y ago
      [flagged]
      • lovasoa 2y ago
        doesn't this apply to most websites on the web?
  • whateveracct 2y ago
    nah at the scale I'm talking about, if you've shipped a produc but your engineers are increasingly dissatisfied with the effort it takes to ship (and are becoming gun shy because you haven't decoupled things so their outage blast radius is huge), then you are currently failing as a technical leader. And if those things are true and you stick to "one Postgres monolithic DB for everything" you are cargo culting too hard. You can't just keep "doing things that don't scale" forever. If you have 100+ engineers [1], you aren't a startup anymore no matter your roots. [1] and remember, my comment that is the ultimate parent of this conversation is about not continuing to do this at 100+. I said nothing about scaling up to that point.
• CalRobert 2y ago
  You could go whole hog with postgrest I suppose
  • jjallen 2y ago
    I always wonder if postgrest works well after growing quite a bit. I really should google the largest companies using it.
    • feverzsj 2y ago
      In my experience, without careful tunning, postgres performance starts dropping significantly around 10 million rows.
      • szundi 2y ago
        We have billions of rows with clustering on one instance, perfect, half a rack almost.
      • natmaka 2y ago
        Without any consideration for I/O? In my experience performance is often directly related to the ratio (total RAM available to Postgresql, shared buffer and buffercache included / total size of tables and indices ), save any weird usage pattern.
      • boomskats 2y ago
        Could you tell us a bit more about your experience?
    • boomskats 2y ago
      Just check out who the key project maintainers are, and then look at who they're employed by. You'll probably recognize the companies. If you don't have schema cache reloading enabled (i.e. you're running it in prod), you can linearly scale postgrest instances pretty much infinitely without impact to the db. Each new instance just costs you a handful of connections and a small amount of memory.
    • 2y ago
• anonzzzies 2y ago
  You don't have to plan this very early; most companies won't get to 100+ engineers. Let's ship first and worry about this, much much much much later. Overarchitecting stuff makes life hard; coming into companies that have 40 servers running with everything architected for 1000000 engineers and billions of visitors while in reality there aren't even 2 users and there is 1 overworked engineer. Stop doing that and stop people telling to do that.
  • szundi 2y ago
    If you die before that, it was the market, not engineers being slow. Of course. Or sales.
  • Cthulhu_ 2y ago
    This (don't overarchitecture stuff) is actually an argument in favor of using e.g. Postgres for everything, as adding more and more tools adds complexity and (architectural) overhead.
  • KronisLV 2y ago
    > Let's ship first and worry about this, much much much much later. Overarchitecting stuff makes life hard; coming into companies that have 40 servers running with everything architected for 1000000 engineers and billions of visitors while in reality there aren't even 2 users and there is 1 overworked engineer. Even if you try to draw boundaries between different bits of the system, you are unlikely to end up with 40 servers, not even close. The average system wouldn't even have 40 separate use cases for PostgreSQL or even the need for 40 different dependencies. However, if you do split it up early, you more realistically would have something along the lines of: * your main database - the main business domain stuff goes here * key-value storage/cache - decoupled from the main instance, because of the decoupling nobody will be tempted to put business domain specific columns here but keep it generic * message queue - for when processing some data takes a bunch of resources but during peak load you need to register a bunch of stuff quickly and process it when you get the capacity * blob storage - to not make the main database bloat a whole bunch, but to keep any binary stuff in a separate instance, provided you don't need S3 compatibility * auth - the actual user data, assuming you use Keycloak or something like it * metrics - all of the APM stuff, like from Apache Skywalking or PostgreSQL Give or take 2-3 services, all of which can run off of a Docker Compose stack locally or with the container management platform of your choice (not even Kubernetes necessarily, but simpler ones like Hashicorp Nomad or even Docker Swarm, using the Compose format). All of which can have their backups be treated similarly, similar approaches to clustering, all of which have similar applicable tools, all of which have similar libraries for integration with any apps and all of which can be granularly inspected in regards to how they perform and scaled as needed. It's arguably better than a single large instance that ends up with 300 tables eventually, has 100 GB of data in the shared test environment and you wouldn't know where to start in regards to making a working local environment if you join a legacy org that isn't using OCI containers and giving each dev a local environment. The single large deployment will rot faster than multiple ones. How many you actually need? Depends on what you do, it wasn't that long ago that GitLab decided to split their singular DB into multiple parts: https://about.gitlab.com/blog/2022/06/02/splitting-database-into-main-and-ci/ https://about.gitlab.com/blog/2022/06/02/splitting-database-... (which also shows that you can get pretty far with a single schema as well, to anyone who wants a counter argument, though they did split in the end) Realistically, if you're doing a personal or small project, everything can be in the same instance because it'll probably never go that far, but I've also seen both monolithic codebases (that are deployed as singleton apps, e.g. not even horizontal scaling) and what shoving all of the data in a single database leads to (regardless of whether it's PostgreSQL or Oracle), it's never pleasant. I'd at the very least look in the direction of splitting out bits of a larger system based on the use case, not even DDD, just like "here's the API and DB instance that process file uploads, they are somewhat decoupled from our business logic in regards to products and shopping carts and all that". Now, would I personally always use PostgreSQL? Not necessarily, since there are also benefits to Redis/Valkey, MinIO, RabbitMQ and others, alongside good integrations with lots of frameworks/libraries that just work out of the box, as opposed to you needing to write a bunch of arguably awkward SQL for PostgreSQL. But the idea of using fewer tools like PostgreSQL for different use cases (that they are still good for) seems sound to me as well.
• qaq 2y ago
  database as API works fine if you have properly abstracted things with sprocs and views. It will be also far less brittle than 100 services exposed as GraphQL
  • Kwpolska 2y ago
    Stored procedures just add overhead and make everyone's lives harder. Forget about any ORMs, you're writing raw SQL with all the quirks of PL/pgSQL biting you all the time.
    • lelanthran 2y ago
      There's advantages too: - marking some columns as NOT NULL. - referential integrity means you can't accidentally have dangling pointers to non-existant dat. - mutually exclusive columns let's the database enforce things like "at least one of A and B needs to be Nonzero, and both cannot be Nonzero at the same time. - create a type that allows only values matching a specific regex. Seriously, if you want strong typing across composite data, there isn't a language invented yet that comes even close to a RDBMS. Of course the majority of Devs don't know any of this because their ORM doesn't expose any of this; it gives them a way to store and query tabular data, and nothing else.
      • pdimitar 2y ago
        None of this prevents you from doing both inside the DB _and_ the app. That way you cover your bases that (1) your app is sound and has maximum amount of fail-early validations to avoid corrupted data states and (2) even if somebody decides to skip the app and try to be clever in a psql console they'll still not be able introduce corrupted data states and (3) leave the door open for other apps to be able to connect to the same DB and do stuff (or simply to allow for a rewrite in another language).
      • Kwpolska 2y ago
        The things you listed aren’t stored procedures, they are all possible to implement as check constraints. They are great, and they are fully compatible with ORMs. A stored procedure is a bit of code, stored in and executed by the database, usually written in a 1960s-era language (like PL/SQL or PL/pgSQL).
• benrutter 2y ago
  I'm so glad to see somebody made this comment!! Postgres for everything is pretty neat in that you can take expertise from one place, and use it somewhere else (or just not have to learn a zillion tools) The same database for everything is a really good way to have a tangled mess (are people still using the word complected?) where nobody knows which parts are depended on by what.
• solatic 2y ago
  Database-as-the-API can scale surprisingly far, particularly if you sell a single-tenant shard to each customer and therefore a separate database to each customer. Drawing logical software boundaries before Product even knows what the domain looks like (i.e. which features will sell) is quite risky.
• ForHackernews 2y ago
  Postgres is inherently multi-tenant. Have separate logic DBs in one physical instance, connect using roles with minimal permissions, expose views (and materialized views!) for querying so you can mutate the underlying tables without requiring applications to change.
  • whateveracct 2y ago
    Great point - wish the people in charge at my job knew that lol