3 ms·

> Databases that are built into the application by default are the future. No they're not, because for web servers, you have many (tens? hundreds? thousands?)

> Databases that are built into the application by default are the future. No they're not, because for web servers, you have many (tens? hundreds? thousands?) of web servers that all need to talk to a single database. And you sure don't want to replicate and sync a gigantic database across each web server -- that would be a disaster. While for local apps on your phone or computer, usage of SQLite is already widespread -- it's not the future, it's here. And cloud-connected apps that work offline already do some sort of sync for that.

secondcoming 2y ago
We have a giant Postgres DB, but instead of having every machine connect directly to it, we have a job that creates a smaller SQLite cache of relevant data and that’s pushed out to the machines who then reload that on the fly. All this depends on your data being somewhat shardable of course.
- aynyc 2y ago
  You can’t really sync the data in real time tho. Transactions still need to hit your Postgres, and then you reload. You might as well do write thru cache.
- binary132 2y ago
  Yeah, this sounds pretty not great if you need ACID consensus or locking between multiple machines. If what you need is to read a somewhat static state, fine, great.
Nathanba 2y ago
Most people don't have tens or thousands of webservers and could be running with a more efficient inprocess database that syncs to another networked readonly replica for a very long time. I'm very surprised that MySQL or Postgres still don't have an inprocess mode because it's such an obvious win and on a technical coding level it should (naively) be very easy to switch from network calls to direct calls.
- crazygringo 2y ago
  But it's standard to have at least 2 webservers. And syncing databases is just waaay harder than having a dedicated one. It really seriously is a pain to configure and debug and manage storage and performance requirements around and dealing with scaling and managing failure modes and so forth. If you can even find someone who has the skills to do it properly so you never lose data. It's far, far easier to just write normal SQL queries that don't have to make hundreds of requests, than to deal with syncing a database across all your webservers.
  - gwd 2y ago
    > But it's standard to have at least 2 webservers. Why do you need 2 webservers (assuming that the cpu / network / disk throughput of a single server is sufficient for your application)?
    - crazygringo 2y ago
      So that when one breaks you have a failover. And because designing for 2 is really different from designing for 1, but not much harder if you do it from the beginning. But expanding from 1 to 2 when you unexpectedly need to because of sudden traffic, and having to re-architect it, can be really hard. I'm not talking about hobby sites here, I'm talking about anything designed for a business, where downtime of a day is unacceptable.
      - gwd 2y ago
        But doesn't the same logic apply to the database? Is the webserver / application layer really so much more CPU intensive (and/or prone to failure) than the database in sites "designed for business", such that you can't get away with not designing the webservers for load balancing, but you can get away with not designing the databases for sharding?
        crazygringo 2y ago
        No to your first question. And yes to your second, unless you're basically at Facebook scale. That's exactly the difference. Databases are astonishingly more optimized and predictable and reliable than web servers.
danielheath 2y ago
> for web servers, you have many (tens? hundreds? thousands?) of web servers that all need to talk to a single database Maybe if you're in the top 1000 or so largest websites. Back when the alexa 10k was a thing, $work was on it - and we're serving that level of traffic with a rails app running on 30 CPU cores. It would fit _easily_ onto a single machine.
- crazygringo 2y ago
  Single machines aren't fault-tolerant. If your machine goes down, your site goes down. And god help you when you have to scale to a second machine and you haven't architected anything for that, and it's a project that takes months. There are a lot of good reasons that we use a fleet of cheap scalable web servers in front of a beefy database server that has a live failover.
  - danielheath 2y ago
    > There are a lot of good reasons that we use a fleet of cheap scalable web servers in front of a beefy database server that has a live failover. "You can't fit on one big machine" is virtually never one of them - and at that point you're firmly in the realm of 'months of bespoke engineering to handle the load'. Similarly, "beefy database server that has a live failover" is not inherently better than "beefy web+database server that has a live failover". I agree there are a lot of good reasons. There used to be a _lot more_ good reasons, and - while I haven't actually tried it yet - I suspect that it's far more tractable than it used to be. If I _were_ to try it, my design would be multiple failover targets (at least 3, geographically dispersed, probably 4), plus a separate control plane to configure BGP.
    - crazygringo 2y ago
      > "You can't fit on one big machine" is virtually never one of them - and at that point you're firmly in the realm of 'months of bespoke engineering to handle the load'. That's just not true. There are a lot of web servers where their operations are CPU- or memory-intensive, depending on what they do. Are they working with images? Mapping? Video? Large data throughput? Especially when so much server code is written in slow interpreted scripted languages. Well-architected databases often can fit on one machine, unless you're at Facebook scale. Webservers however -- absolutely not. The front-end for a simple CRUD interface, or for a blog with static pages, sure. But for a lot of interactive sites, definitely not.

secondcoming 2y ago

We have a giant Postgres DB, but instead of having every machine connect directly to it, we have a job that creates a smaller SQLite cache of relevant data and that’s pushed out to the machines who then reload that on the fly. All this depends on your data being somewhat shardable of course.

aynyc 2y ago
You can’t really sync the data in real time tho. Transactions still need to hit your Postgres, and then you reload. You might as well do write thru cache.
binary132 2y ago
Yeah, this sounds pretty not great if you need ACID consensus or locking between multiple machines. If what you need is to read a somewhat static state, fine, great.

Nathanba 2y ago

Most people don't have tens or thousands of webservers and could be running with a more efficient inprocess database that syncs to another networked readonly replica for a very long time. I'm very surprised that MySQL or Postgres still don't have an inprocess mode because it's such an obvious win and on a technical coding level it should (naively) be very easy to switch from network calls to direct calls.

crazygringo 2y ago
But it's standard to have at least 2 webservers. And syncing databases is just waaay harder than having a dedicated one. It really seriously is a pain to configure and debug and manage storage and performance requirements around and dealing with scaling and managing failure modes and so forth. If you can even find someone who has the skills to do it properly so you never lose data. It's far, far easier to just write normal SQL queries that don't have to make hundreds of requests, than to deal with syncing a database across all your webservers.
- gwd 2y ago
  > But it's standard to have at least 2 webservers. Why do you need 2 webservers (assuming that the cpu / network / disk throughput of a single server is sufficient for your application)?
  - crazygringo 2y ago
    So that when one breaks you have a failover. And because designing for 2 is really different from designing for 1, but not much harder if you do it from the beginning. But expanding from 1 to 2 when you unexpectedly need to because of sudden traffic, and having to re-architect it, can be really hard. I'm not talking about hobby sites here, I'm talking about anything designed for a business, where downtime of a day is unacceptable.
    - gwd 2y ago
      But doesn't the same logic apply to the database? Is the webserver / application layer really so much more CPU intensive (and/or prone to failure) than the database in sites "designed for business", such that you can't get away with not designing the webservers for load balancing, but you can get away with not designing the databases for sharding?
      - crazygringo 2y ago
        No to your first question. And yes to your second, unless you're basically at Facebook scale. That's exactly the difference. Databases are astonishingly more optimized and predictable and reliable than web servers.

danielheath 2y ago

> for web servers, you have many (tens? hundreds? thousands?) of web servers that all need to talk to a single database Maybe if you're in the top 1000 or so largest websites. Back when the alexa 10k was a thing, $work was on it - and we're serving that level of traffic with a rails app running on 30 CPU cores. It would fit _easily_ onto a single machine.

crazygringo 2y ago
Single machines aren't fault-tolerant. If your machine goes down, your site goes down. And god help you when you have to scale to a second machine and you haven't architected anything for that, and it's a project that takes months. There are a lot of good reasons that we use a fleet of cheap scalable web servers in front of a beefy database server that has a live failover.
- danielheath 2y ago
  > There are a lot of good reasons that we use a fleet of cheap scalable web servers in front of a beefy database server that has a live failover. "You can't fit on one big machine" is virtually never one of them - and at that point you're firmly in the realm of 'months of bespoke engineering to handle the load'. Similarly, "beefy database server that has a live failover" is not inherently better than "beefy web+database server that has a live failover". I agree there are a lot of good reasons. There used to be a _lot more_ good reasons, and - while I haven't actually tried it yet - I suspect that it's far more tractable than it used to be. If I _were_ to try it, my design would be multiple failover targets (at least 3, geographically dispersed, probably 4), plus a separate control plane to configure BGP.
  - crazygringo 2y ago
    > "You can't fit on one big machine" is virtually never one of them - and at that point you're firmly in the realm of 'months of bespoke engineering to handle the load'. That's just not true. There are a lot of web servers where their operations are CPU- or memory-intensive, depending on what they do. Are they working with images? Mapping? Video? Large data throughput? Especially when so much server code is written in slow interpreted scripted languages. Well-architected databases often can fit on one machine, unless you're at Facebook scale. Webservers however -- absolutely not. The front-end for a simple CRUD interface, or for a blog with static pages, sure. But for a lot of interactive sites, definitely not.