Utility wise, naming feedback is much useful.

For any database product, there are plenty of mature and robust technical tools for improving and evaluation. I do not believe the company is less aware of any HN commenter. Therefore any technical feedback only going to have limited impact.

But the naming feedback seriously helps them get an idea how their naming hurts their brand-acceptance.

By all means, that's a valuable feedback.

"We settled on postgresql, because, despite going into toast tables and having to implement sharding on top"

This is a common mistake. The choice doesn't actually guarantee consistency at all. PostgreSQL only guarantees consistency as long as you don't try to communicate with it over a network, which you obviously do if you have shards. To address this problem we have things like 2pc, but they aren't very useful for an RDBMS on their own without the whole infrastructure of a distributed database.

The networking isn't a problem if you only acknowledge a write when the underlying database says so. You could have a write succeed before you crash. But you won't lose an acknowledged write.

No, but when your requirement is to "never loose a write regardless of which server fails" you have to make sure the mutation was acknowledged by more than one server.

So the least you have to do is to wait for a second server to confirm the write. But now what do you do when the network link between the two servers goes down in-between a write? The write might have already been applied on the first server or it might not have. The same goes for the second server. But you can't be sure either way.

For our thought experiment, let's assume that while the servers can't talk to each other anymore, some clients can still talk to each of the servers.

At this point, you either have to give up availability (i.e. don't accept any further writes until the fault is resolved) or consistency (i.e. potentially return unacknowledged/stale data from one of the nodes until the fault is resolved).

While returning unacknowledged/stale data is acceptable for some usecases, it does break ACID semantics. You can't get both ACID and "always-on" availability with a simple replication scheme like this.

If you want linearizability and HA, you need at least three servers and a more complex, quorum-based scheme. However, Postgres doesn't support that (AFAIK) - you have to use something like Zookeeper or CockroachDB. I think this is what zzzcpan meant.

(I realize that you only spoke about never loosing a write and didn't say anything about updates/queries. If you don't care about ACID, postgres with synchronous replication is a good highly available solution)

You're taking the wrong approach.

We don't have auto-healing HA, you have 32 master databases which have replica databases underneath them with synchronous replication. Meaning things must be synced to both before the COMMIT OK is received by the client.

Then you do the sharding logic in the application.

No write can be sent back as being "OK" unless it's on disk on 2 servers which represent a vertical slice of our entire database structure.

We assume power-loss scenarios mostly, which means if it's on disk and not in vfs then we're fine- as power-loss is more likely than complete raid degradation or server disappearance, although the replicas help with that too.

You don't need quorum at all in this scenario, and no matter which database or client fails you will not lose data that you've acknowledged, even on immediate power loss to 50% of your entire infra.

So what do you do when the master for one of your shards fails? Do you drop all incoming writes for the shard on the floor? Or do you fail over to the shard's slave and promote the slave to the new master?

Since you said you don't have "auto healing HA" I assume you don't fail over, but discard/deny incoming writes until the master comes back up.

This is a valid approach, but, I don't see how it contradicts what I said at all:

  - I said you can't get full ACID and HA failover at the same time with postgres
  
  - Your scheme does not provide HA failover

I explicitly said that if you can forgo either full ACID or HA in case of a failure, postgres is fine.

It's not bikeshedding at all. It looks like a good solution, but many people have concerns about an inability to use it because of management/clients and the connotation of the name. That's a legitimate concern. Don't just hand wave it away.

It's not bikeshedding. Who the fuck wants to work for a company called Cockroach Labs? Seriously, sure your tech friends and recruiters might appreciate it on your resume but anyone outside of tech? Applying for an apartment, mortgage, car, lol good luck. And also not too sure that anyone outside the immediate tech/startup nerd scene would appreciate it other.

That aside why the hell do I want to thing of cockroaches day in and day out when I am using their product? Seriously, is this someone's idea of a bad joke?

The name has got to go.

Nobody is going to give a flying fuck what your company is named on a mortgage application.

Honestly there are companies with _much_ worse names in active use like "Dick & Daughters"[0] or "Ismail ANUS"[1] who even got an appointment to the queen.

Seriously, it's bikeshedding, and the point of the DB is that you don't think about it all day.

I also don't think of women called Cassandra when I use the database of the same name. Bikeshedding. Seriously.

[0] https://beta.companieshouse.gov.uk/company/08610385

[1] https://beta.companieshouse.gov.uk/officers/5-sFnEsibrDnUR2-...

Just one Dick, not "Dicks", and you posted the same link twice :D

oops, thanks for pointing that out.

Dick & Daughters or Ismael ANUS are definitely not more vile then Cockroach. The former are names rooted in tradition, not some idea of a an arrogant hipster joke. To call a company Cockroach is fucken arrogance. Plain and Simple.

Cockroach is just a creature. How is it arrogance. It reeks of arrogance to call yourself "Lionhead" or "Jaguar" or "Oracle". Some form of apex predator or all-knowing entity.

Also "Is Male Anus" is not rooted in tradition at all.

"Who the fuck wants to put their bikes in a magenta shed?"

It would be bikeshedding if we were all, for no good reason and without prompting, suggesting names that we preferred, with no consensus emerging.

Instead what I see in this thread is a clear consensus that the current name is atrocious, even to the point of being detrimental to the long-term success of the project, and should therefore be changed.

Personally, I refuse to use or recommend this product as long as its current name remains. And to those who think I'm being petty, 1) I can afford to be petty given how many database options (NoSQL or otherwise) are out there, and 2) market forces should punish products with names like this, or else we'll eventually find ourselves debating the merits of HerpesDB vs. ManureDB.