4 ms·

I don't think most people would disagree with that. If you want to build a database, for curiosity, or to solve a particular problem, or just because it seems f

by mjb 3y ago

I don't think most people would disagree with that. If you want to build a database, for curiosity, or to solve a particular problem, or just because it seems fun, go ahead. But know that making a real production database tends to be harder than it looks, and so tends to be all-consuming, and a team that depends on a custom database tends to become a database team rather than an anything else team. That could be the right thing - after all building databases as an explicit goal has lead to a lot of very good businesses - but you need to go into it with your eyes open. Building a production-quality database is a long road. The same is true of some other areas, like durable storage systems, filesystems, and compute isolation/virtualization systems. In all these cases going from zero to "undergrad quality demo" is doable in a couple days. Going from demo to running something in production is vastly harder and more expensive and requires a completely different mind set. Building the "undergrad quality demo" is a great exercise I'd recommend to anybody curious about these areas. The road to production, however, is a tougher one. Source: I build and maintain databases for a living at AWS. One of my previous side projects (https://www.usenix.org/conference/nsdi20/presentation/brooker https://www.usenix.org/conference/nsdi20/presentation/brooke...) turned out to be bigger than expected and has a whole team dedicated to it. That one (Physalia) is even quite far from being a general database (for example it doesn't support SQL or cross-shard transactions).

hftthw 3y ago
[dead]
rewmie 3y ago
> But know that making a real production database tends to be harder than it looks, and so tends to be all-consuming, and a team that depends on a custom database tends to become a database team rather than an anything else team. The original statement does not include any caveat or constraint, and is an absolute statement that does not depend on specifics. The statement is not "Never write a custom database as a subproject of any other project". The original statement is "Never write a database." Like in any conceivable scenario, including a project whose main goal is to write a database. I also feel that this sort of clickbait advice contrasts heavily with the history of SQLite.
- ncphillips 3y ago
  The tweet doesn’t but the context of the tweet is a conversation about building a custom database to power a business.
  - coldtea 3y ago
    Well, the company I worked at did, and it worked out just fine. Not even that many people involved, like 3-4, the main architect and coder had never done a DB before (but is a genius anyway). For the scope and within that domain (not relational, heavy writes), the performance smokes anything out there. In production for over a decade now.
- derefr 3y ago
  It is a statement directed at a readership of — and therefore assuming it will only be read by — application developers, rather than systems programmers; and so the context of "Never write a custom database as a subproject of any other project" is implicit. Also, you're reacting to an incomplete quote. The tweet is: > "Never write a database. Even if you want to, even if you think you should. Resist. Never write a database. Unless you have to write a database. But you don't." There are precisely two cases where you "have to write a database": 1. when you want to learn how databases are architected, and educational material on the ground is wholly inadequate (which it is!); and 2. when you discover, under a production workload, that no existing DBMS sits in exactly the right part of DBMS configuration-space to meet your scaling needs — and nor can any existing DBMS even be modified to reach that point in DBMS configuration-space — and nor can you modify the design of your application to scale in a different way; such that the only possible way to address your scaling challenges is to write an entirely novel DBMS with an entirely novel architecture. I can only think of two times #2 has happened in recent memory: Amazon with Dynamo (the core of S3 and DynamoDB); and Google with Dremel (the core of BigQuery.) Both projects have resulted in many research papers, and later copycat DBMSes (Dynamo → Cassandra, Riak, BigTable, etc; Dremel → Redshift, Snowflake, etc.) If you don't think your DB architecture is novel enough to result in that kind of response, then it's probably not something that requires "writing a database" — it's probably instead something you can do as a hack on top of some existing database. (Think: the way Citus/Timescale/Greenplum build on Postgres.)

by mjb 3y ago

hftthw 3y ago

[dead]

rewmie 3y ago

> But know that making a real production database tends to be harder than it looks, and so tends to be all-consuming, and a team that depends on a custom database tends to become a database team rather than an anything else team. The original statement does not include any caveat or constraint, and is an absolute statement that does not depend on specifics. The statement is not "Never write a custom database as a subproject of any other project". The original statement is "Never write a database." Like in any conceivable scenario, including a project whose main goal is to write a database. I also feel that this sort of clickbait advice contrasts heavily with the history of SQLite.

ncphillips 3y ago
The tweet doesn’t but the context of the tweet is a conversation about building a custom database to power a business.
- coldtea 3y ago
  Well, the company I worked at did, and it worked out just fine. Not even that many people involved, like 3-4, the main architect and coder had never done a DB before (but is a genius anyway). For the scope and within that domain (not relational, heavy writes), the performance smokes anything out there. In production for over a decade now.
derefr 3y ago
It is a statement directed at a readership of — and therefore assuming it will only be read by — application developers, rather than systems programmers; and so the context of "Never write a custom database as a subproject of any other project" is implicit. Also, you're reacting to an incomplete quote. The tweet is: > "Never write a database. Even if you want to, even if you think you should. Resist. Never write a database. Unless you have to write a database. But you don't." There are precisely two cases where you "have to write a database": 1. when you want to learn how databases are architected, and educational material on the ground is wholly inadequate (which it is!); and 2. when you discover, under a production workload, that no existing DBMS sits in exactly the right part of DBMS configuration-space to meet your scaling needs — and nor can any existing DBMS even be modified to reach that point in DBMS configuration-space — and nor can you modify the design of your application to scale in a different way; such that the only possible way to address your scaling challenges is to write an entirely novel DBMS with an entirely novel architecture. I can only think of two times #2 has happened in recent memory: Amazon with Dynamo (the core of S3 and DynamoDB); and Google with Dremel (the core of BigQuery.) Both projects have resulted in many research papers, and later copycat DBMSes (Dynamo → Cassandra, Riak, BigTable, etc; Dremel → Redshift, Snowflake, etc.) If you don't think your DB architecture is novel enough to result in that kind of response, then it's probably not something that requires "writing a database" — it's probably instead something you can do as a hack on top of some existing database. (Think: the way Citus/Timescale/Greenplum build on Postgres.)