Apply HN: Brodlist – a new type of database | Hacker News Reader

Apply HN: Brodlist – a new type of database

46 pointsdavid92780 comments

Brodlist (http://brodlist.com) is new ground-breaking database that aims to replace the relational database.

Its features include Schema-on-Need, so that you don't have to model your database, just start using it. History is built in. You can query the current state of your data or how it looked a week or month ago just by specifying 'when' as part of the query. It's performant on commodity hardware and scales horizontally, which is why we can offer it for next-to-nothing. Because it's offered as a REST-ful service where the language is the interface, your API is built-in. What's more, the authorization is specified as queries, so you can easily lock down any set of rows or columns for any user.

Finally, it uses a new query language that is much simpler. To get the list of employee equipment in the Sales Department would be queried like this: Employee.Equipment : Employee.Department = "Sales"

The same result in SQL requires this query: SELECT q.* FROM Equipment q INNER JOIN EmployeeEquipment ee ON ee.EquipmentKey = q.ID INNER JOIN Employee e ON ee.EmployeeKey = e.ID INNER JOIN EmployeeDepartment ed ON ed.EmployeeKey = e.ID INNER JOIN Department d ON d.ID = ed.DepartmentKey AND d.Name = 'Sales'

SQL and the relational database has been around for 50 years. It's finally met its match.

View on HN

1) Describe the team and why they're qualified to build a distributed database from the ground up.

2) What is the advantage compared with Postgres + Postgrest[1]? Considerations:

  a) Extensibility (e.g. PostGIS)
  b) Hosting (for large enterprises, cloud database may be a non-starter.)
  c) Stability
  d) Community
  e) Documentation
  f) Security

Databases are scary.[2] As a developer, you would have to convince me that nothing would ever break since I damn sure am unqualified to be monkeying around in that code. As a CEO, you would have to convince me nothing would ever go down and this provides a significant advantage over Postgres. As a technical co-founder, you would have to convince me that you aren't going anywhere and will be able to build a substantial community.

[1]: https://github.com/begriffs/postgrest [2]: That isn't a reason not to do it.

I find it interesting that your first question is about why the founders are the right ones to build this and the second is about how it's different than existing solutions.

Usually the idea gets discussed, than the team and competition. I think it is telling that the top comment on this post doesn't need to validate the idea and demand. That alone should count for considering in the YC Fellowship.

A distinction without a difference. Both are things that investors would care about.

Sorry but if this is the first experience the team has with building or maintaining data stores then I would definitely not invest. There is so much to learn from experience.

Having said that, I imagine it's not, so it should be an easy question to answer one would hope.

Of course the questions are important. My only point is that the idea itself seems to resonate really well with the voters on HN, since the questions jump to execution related questions and bypass idea validation questions.

> first experience the team has with building or maintaining data stores then I would definitely not invest.

To that point, while admittedly I don't know enough about building and maintaining data stores, I think it is a mistake to pass on founders because they lack the experience needed to know what they are up against. Often it is that very quality of being too naive to know what they are up against that allows them to take on a massive project and completely change the world or disrupt an industry.

I think the questions are fair and important to answer, I just think that great things are done all the time by people who have no clue what they are doing or up against going into the challenge...as long as they have the perseverance and resourcefulness to deal with whatever gets thrown at them, I would bet on them.

When I have heard YC partners talk about judging companies, they put a heavy emphasis on the founding team. (Their background, how long they have known each other, and why they are the right person to build this product.) So I think it is a perfectly valid question.

Of course it's an important question, but it's rarely the first question. The first question is usually about why the idea is good in the first place. The next line of questioning is about the market opportunity. If you make it through those two lines of questioning, than they figure out if the team is the right team for this project.

I was only pointing out that the idea itself seems to resonate enough with the voters on HN that they don't question the validity of the idea, only the ability of the team to deliver.

Everyone wants a faster, lighter, more energy efficient, and reliable car, am I right?

That's why this comes up.

It simply not as much of a question of is the idea great, it's we have been here before (and if not exactly this idea, there is a lot of overlap with other new databases), and it's quite hard to pull off.

Not everyone can be the tesla of databases, and there is a plethora of new options in the space. So answering this question seems to weigh a bit heavy in the discussion for good reason.

But Elon Musk doesn't have 20 years of experience at Ford. Sometimes, when you are doing something new, it comes from left field.

Brodlist stems from several years of private research with two PhD students (check kayia.org for more details) that was lucky enough to wind up being able to be the Tesla of databases. Most of this is implemented (what's left is mechanical) and I'm happy to do a TDD with HN. I definitely understand your concern and I'm saying I don't know if we qualified to do this job but I can assure you that we qualified by doing this job.

Sure, but Elon Musk is one person. Tesla is a team.

Tesla has hired the brightest minds in the business, _plenty_ coming from years and years and years of deep experience building cars, supply chains, and more.

You can believe that he didn't get funding without having the team in place to build his company, even if he is the fire starter.

Someone might read that and think you're directly arguing that companies shouldn't get funded if they start in a garage. :)

I should have never thought I could try to do something so disruptive and during the long process till now there were many times I wished I could have killed the muse that started it all. It was the hardest thing I've ever done and yet, still, looking back, I don't regret a thing.

I think if you could look at what it took to bring it to this point, you would never doubt if it has what it will take to go the rest of the way.

But it's still early -- I know. A YC Fellowship is for prototype stage companies and that kind of funding isn't for everyone -- I get that. And I get your concern for exactly what it is: concern. It's valid, really, and I appreciate it. But if I could have done the smart thing and walk away, I would have done it a long time ago.

The fact that MongoDB exists and is, despite all good sense to the contrary, still actively adopted by people for various projects belies the idea that stuff is a necessary prerequisite to success.

Your example of MongoDB brings up the most important issue with this company.

As HN users, we're all curious about and focusing on the technology, but the technology doesn't seem to dictate winners and losers.

Mongo "won" (to the extent that it won) because it had some kind of excellent mixture of luck and marketing. How will Brodlist succeed?

I imagine the marketing talent would have to be absolutely incredible.

You're right of course, databases are scary. And they're the foundation of your application so they have to work and always work. We get that.

If you're asking in [2] how it can compete with Postgres on Stability, Community, Documentation, of course it can't yet. Postgres didn't have them when it started either. But the feature set is compelling and if enough people want those features then these signs of maturity will emerge as well.

To answer question [1], I am the technical founder and I presented the core technology as Kayia.org at the Future of Programming Workshop at StrangeLoop a little over a year ago. I wasn't qualified to do this research when I started but after knocking at the right door long enough, it opened. I'm happy to work with HN on TDD.

It's early for Brodlist, yes, and I understand your point about needing certainty but please give us the opportunity to make something you'll both love and know you can rely on.

"We can't compete with Postgres yet, but please fund us anyway and we'll surely figure it out later" is not exactly a compelling plan that makes me want to invest.

I suggest that you need to work out how you plan to compete, at least in general terms, before you ask people for money to do it. "Just trust me" is not going to get you very far.

I didn't say that and I'm starting to not be sure that you're being objective.

The feature set listed above easily beats Postgres by any measure expect maturity. Your question asked how it competes on maturity -- how old is it? It's new. We're applying for the YC Fellowship which funds prototype stage companies.

Since this is a distributed database, there are a few questions I have:

1. How does it handle network failures where the nodes have a mixed ability to communicate to each other? (Server A can talk to B, but not C. C can talk to B but not A)

2. How does it manage hosts with widely differing clocks?

If these haven't been developed/tested yet, how do you plan on solving those issues?

Great questions. Thank you!

Right now it's distributed on the same host and your guess is right, that hasn't been developed yet. The replication is mirrored with a central dispatch so that if a node isn't available , the other two provide a quorum. Widely differing clocks would be an issue and will require a lot of thought. I've already appealed for help to some very smart people I know and might have to do so again.

> I've already appealed for help to some very smart people I know and might have to do so again.

Without knowing anything about this industry, technology or these founders, this phrase alone gives me enough confidence in their ability to execute on this or anything else they commit to.

Was that sarcasm? To me it looks like these guys don't have an idea what they are doing. They advertise features which as well might be close to impossible. And their strategy is to appeal for experts? If they can deliver this, they should have quite good picture themselves how to deliver.

The feature set was backed-into, in the sense that the technology came first and it was found it could and does support these features. We didn't make a shopping list of features and are now declaring we want to do that. Our research found a shopping list of features.

I'm not saying we have to appeal to experts, I'm saying we want to. We've come this far, out-of-sync clocks on different hosts is certainly not going to stop us. But I mentioned asking experts because we've done it before and we will continue to do it again along the way, because one of the biggest mistakes as a founder that you can make is to think that you have all the answers.

Finding smart people and trusting them is a separate skill and it's one to say that I'm proud that we have.

It was not sarcasm. We are not supposed to do things ourselves. We are supposed to lean on experts, face our shortcomings and be brave enough to admit when we need help.

This quality of willing to ask for help is way more important than any specific experience.

They do need to know what they dont know. So they need a vision and picture of how to deliver...but that vision can and should include leaning on others IMO.

Your product pitch is very similar to the product pitch for Neo4j, a graph database which already has significant adoption: http://neo4j.com/product/

How does your database differ from graph databases?

Neo4j is great for what it does but if you look closely at the offering and read through the feature set (look particularly at the query language, for example), you can see the differences.

This is a relational database and is chasing that market; its competitors are MySQL, Postgres, etc.

1) What language is the database written in?

2) What are the key benefits of designing a new DSL for this database?

3) Given that it uses a built-in API, will security audits results be made public?

4) It seems to save "snapshots" of different moments in time. How does that affect database size? Does each snapshot act as its own database instance or is it just a data backup?

5) How do you plan to introduce and train programmers into using various different concepts at once? What kind of strategy do you plan to leverage for mind share?

6) You mention replacing the relation database. Explain how this is better than Microsoft's SQL Server. [Comparing a paid product against another rather than to a free one.]

7) Will this be offered as a stand alone product or as a service?

8) What other databases (or systems with similar complexities) has the team worked on / built ?

9) What makes this a must have standout product from other databases out there?

1) C++ 2) It's clearer and allows for more powerful constructs (even if they're not being talked about yet). 3) Yes. 4) It depends on the number of writes but you can adjust the level of history to the level you want. 5) Great question. I'll have to circle back to this later. 6) The feature list above beats SQL Sever on each point. 7) Initially as a service but that could change. 8) The research stems from the Kayia programming language (kayia.org). 9) The feature set for the price. It solves a lot of back-end needs and yet is much cheaper.

Do you have any documentation regarding the DSL? I'm interested in looking into this. Feel free to email me (check profile) with more information.

I apologize for the lack of information on the site. I'll add a lot more to the site soon including a REPL. You can find something for now at kayia.org.

Thank you so much for your interest!

I will look into it, thank you.

Why didn't you use Rust? (I swear I'm not a troll, and I'm genuinely curious.)

Why rust? Why not using Go instead of C++

Why Rust? Because Rust has excellent concurrency support and memory safety, both of which are useful for databases.

For something as low-level and performance-intensive as a database intended to replace MySQL/Postgres, Go wouldn't work because it's garbage collected.

I feel Rust is still not old enough to be used on databases. It is a relatively new language with an amazing future. But it might not be a good choice for a new product that is meant to be the workhorse of a system. C++ is the correct and safe choice under the circumstances. Good question though. Its always beneficial to question architectural choices in order to see the other side of the coin. :)

It might be because I was watching MemSQL for a long time, but I think Brodlist is probably years away from being used in production. Rust is stable now, so I think there's an acceptable tradeoff between the risk of Rust lacking an ecosystem and the benefits of using Rust.

Anyway, it doesn't matter that much in the end. I was just curious.

Go is used on many low-level performance-intensive databases, InfluxDB, CockroachDB and etcd just off the top of my head.

How does this compare to Datomic? The model seems similar.

Datomic is awesome and I'm a huge Rich Hickey fan.

The language is different and I believe better, and having history/versioning of the data baked-in is a big plus in our column. I could make a deeper comparison if you'd like.

I haven't used Datomic but I thought its entire premise is that the data is immutable and thus history/versioning was baked in. Am I missing something?

That is indeed the premise of Datomic, so I'm not sure how that would be a differentiator in this case. Beyond that, it's hard to make any statements on the difference between the query languages without more examples.

Baked-in as part of the language; the query language is where it stands out. I'll get you examples of that.

FWIW, You can get transaction-time and the associated wall clock time in datomic's query language as well, though admittedly I can imagine cleaner ways of doing it :)

http://stackoverflow.com/questions/11025434/in-datomic-how-d...

Cool; I didn't know that. Thanks, Chris.

I'm sorry we missed you at coffee on Saturday. The next one is in two months -- hope to see you then if you have time.

Sounds really interesting.

When will it be available for testing and how will it be licensed, open source?

Thanks. At its current pace it will be available for testing in four to six months. I'm not sure yet about open source but I'm very open to it. Licensing is still up in the air.

Could you explain what you mean by "Schema-On-Need"? I can just get start using a database with no schema, but I assume Schema-on-Need is different from that.

In the example above, if Employees are only in one Department and suddenly you have the situation where an employee is in more than one department, you don't need to create a link table to model that. In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start, it can just emerge as you go.

Sounds like new words to describe what graph databases do. Although I see you answered another question already comparing to Neo4J.

So are you just providing an API and the database will be stored on your server? Or will users install it on their own hardware?

Initially we're providing an API but the idea of open sourcing it is very much on the table, which of course would allow users to install it on their own hardware.

Correct me if I am wrong, but won't latency be an issue if connecting to a DB via an API? I would imagine that would be a deal breaker for most (especially for me).

Great question! This is where other DaaS's have struggled and this is where we shine. The authorization model is robust enough that you can obviate a lot of the business-logic layer.

Building a sports site and only friends of team members or the team members themselves can message each other? Build it in your authorization model. The UI will only see appropriate recipients and only be able to send messages to them. In other words, a lot of your architecture could become UI-DB direct and only a portion going through a business layer.

(0) Regarding Schema-on-Need, let's assume the following scenario: When I begin developing an application, I'm not quite sure what my data model should be, so I insert data into the database without defining a schema. A few months later, I have a clearer idea of the data model I want, but my existing data set doesn't fit exactly in this model. Do you provide some way to “fit my database to a schema”?

(1) Could you provide a proper specification of Brodlist's query language? Your example is too small to convince me that Brodilist's query language can express everything SQL can express.

(2) Could you provide an example of a nontrivial application (like a small ERP module) that illustrates how Brodlist is more convenient to use than a traditional SQL DBMS?

(0) The idea is not to start without any schema but to start with one and then let it develop. In the example above, if Employees are only in one department and suddenly you have the situation where an employee is in more than one department, you don't need to create a link table to model that. In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start, it can just emerge as you go.

(1) You can find more at Kayia.org but more will be posted on the site soon.

(2) A nontrivial application example is not available just yet and I agree with you that it would a great place to examine its trade-offs. The next several months will be quite busy but if you could please check in after that and I think we can eventually get you an answer you'll be quite pleased with.

> In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start,

So, which is it: do I begin with a schema or not? If I don't need to think about the cardinality of relationships, then I don't have a schema. (My definition of “schema” is “a DBMS-enforced description of the logical structure of a database”. If I don't have to think about it, how can the DBMS enforce it?)

> You can find more at Kayia.org

The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website.

If you only want there to be one department per employee, you can constrain that relationship and the database enforces it. When an additional department is attempted to be added for an employee, it won't be allowed. If you have a list of Films, their title, release date and director, and you don't want additional columns to be allowed to be added, you can set that constraint as well.

Let's say now you find out that one film has two directors (a change in relationship cardinality). If you have not constrained it, the default is to allow that to happen.

You have schema. The default, though, is to let the data tell you what it is rather than the other way around.

> Kayia.org The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website.

There's also a lot of missing information. My apologies; fixes are coming. We didn't plan to submit this to Apply HN -- the opportunity just jumped and so did we. We should have waited and fixed those things and then submitted. Again, apologies, changes are coming.

Sounds neat!

What's the performance tradeoff, if any?

How far along development is it? Beta? Production ready?

Thank you so much!

I don't have direct competitive benchmarks but it reads and writes at around 620k/qps.

It's in alpha right now at about 80% of completion.

You have symmetric read and write rates? That's pretty odd. Also if you are writing at that rate, presumably those writes aren't persisted?

EDIT: That's also a rate of 1.6us per query. I've never heard of a JSON/REST stack that could take in and return results in that period of time. Are you doing something special to accomplish that?

I couldn't remember the write speed but it's about 80% of the read speed. The writes are persisted. The qps rates are for individual look-ups and do not include any HTTP latency, of course.

Good evening...

I have a couple of general statements and questions.

1.) Good job on getting this far and congrats on making it to the first page. This is the first 'apply HN' that I've seen! :)

2.) You have a neat idea, so I did some research. I found an Indiegogo campaign backed up by a few Reddit posts, some HN posts, etc. How did your project (the semantic search engine) go? It sounds similar to this pitch - does the technology for this project stem from that project? What have you learned?

3.) How do you pronounce Brodlist? Is it broad list? Or maybe Bro D. List?

1) Thanks!

2) No one was interested in the technology as powering a semantic web search engine. I think Fred Wilson said something to the effect of, "Who would want this?"

3) It's pronounced 'broad list'.

What's your business model?

Will you be open sourcing the backend server?

Why would anyone want to us this over the plethora of other choices for a persistent storage layer?

Honestly, your example syntax doesn't look that appealing. I'm not saying SQL doesn't have its warts but if you're going to replace it, doing it at the language level integrated with a 4GL makes more sense (ex: like how rethinkdb rolls queries).

Who's the target user for a new system like this, why would they use it, and why would they pay you?

What's your business model?

Currently, hosting fees. We pay 3€/month and charge 10€ per 10GB instance. That could change and expand, though.

Will you be open sourcing the backend server?

Not initially but I'm very open to the idea. I think it would remedy a lot of the concerns voiced so far in this thread.

Why would anyone want to us this over the plethora of other choices for a persistent storage layer?

Someone else above wrote, "Everyone wants a faster, lighter, more energy efficient, and reliable car, am I right?" indicating that everyone would want it but doubting that it can launch. If you're using MySQL, Postgres or SQL Server as your database right now, you would be hurting your project to not change. To pick just two features, Schema-on-Need allows you to extend and expand according to the data, not your pre-conceived notion of how the data is structured, and the query language, which leads me to the next question:

Honestly, your example syntax doesn't look that appealing.

Maybe, to you. Here's the thing I'd like you to consider: it's not about you. The majority of users that we've talked to who don't know SQL find it easier to work with. The bigger reason still is that it maps nicely to BI tools. The key here is that we need to open up data access to more non-experts.

Who's the target user for a new system like this, why would they use it, and why would they pay you?

Target user: SME, startup currently using a relational database

Why would they use it: "Everyone wants a faster, lighter, more energy efficient, and reliable car, am I right?" (The longer answer is in that same paragraph above.)

Why would they pay: Because it pays. It gives them the features they want and at the same time saves them money. It can cost a startup several thousand every month to run a SQL Server Azure instance, for example, that would cost less than 50 with Brodlist, with more features.

Marketing question: How do you plan to acquire customers? What channels will you use to get the word out?

There are already dozens of very actively used databases out there. Some of them have track records that are decades long. There are dozens more new entrants into the market every year.

How, in a marketing sense (not a technical sense) will you compete with them to get the word out and convince people that they should go with your solution instead of another?

Thanks for the great question.

How do you plan to acquire customers? What channels will you use to get the word out?

Even though we're not officially in beta, we already have a customer we're working with and we've been curating a list of prospects for our beta who have a high-degree of both interest and pain (usually due to the amount they're paying every month, but also due to managing complexity). We'll work with them first, rather than a big launch event, and slowly start to market to other customers, mainly newly forming start-ups at first. (Which is another reason why a YC Fellowship could be very useful to us.) This market is highly reputation-based, which means word-of-mouth is more powerful than other markets. Our market research tells us that based on the feature set specified, prospects would not only find it compelling enough to evaluate but they said if it matches or exceeds expectations, they would be willing to tell others. Our channels for this initial market are mainly direct: talking to directly to companies in accelerators and incubators, meetups for startups, etc.

There are already dozens of very actively used databases out there. Some of them have track records that are decades long. There are dozens more new entrants into the market every year. How, in a marketing sense (not a technical sense) will you compete with them to get the word out and convince people that they should go with your solution instead of another?

We have things easier and harder than a normal product. With an app you can have a harder time clarify your offering but an easier time getting adoption. It's the opposite for us. To be embraced and see high rates of adoption, we have to be more than fractionally better than others in our segment. We have to be so much better that we exceed the risk costs of switching (or adopting) new technology and the risk of relying on an initially small firm. So far, our market research says that when we state our offering, our feature set, the value is usually quickly perceived. Someone in this thread referred to us as aiming to be the Tesla of databases -- that's it. But we have to pair that with immaculate execution.

We're applying to the YC fellowship to give us the best possible odds for that type of execution (as well as potentially increase our pool of first customers).

What programming language is it built in?

Not sure. Don't know. C++.

Can you elaborate on this. In another comment you said:

> "It's in alpha right now at about 80% of completion."

confused but curious thanks!

The comment was initally three questions and was edited down to one. It's 100% written in C++. Sorry for the confusion.

How is this different than Mongo with a little query language DSL on top?

If you want to look at it that way, I won't stop you, but it's really not a popular comparison.

Brodlist is a relational database and the query language is both quite powerful and, for some, simpler than SQL.

I don't want to look at it in any particular way.

I was asking for clarification, to see whether I understand the features correctly, and to determine what customers get by using your product.

So the question remains: what does the customer get beyond using, say, Mongo? You say it's a relational database, but the Schema-On-Need feature sounds awfully NoSQLish. What's the point of using a fixed schema at all if it simply creates new fields on demand whenever you try to insert a nonexistent field? Why not just use Mongo in that case?

Having a new query language that some people like is nice, but how do you plan to build a company around that?

Why is it different or better than the hundreds of other query languages out there?

Thanks for getting back to me -- to be honest, the question as it stood was confusing for me. Ok, I see what you're asking now and I apologize for not asking for more clarification. It's a really good question as are the additional questions here, so let me get to it.

Do you remember when DropBox was announced on HN? One of the top responses was, "1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software."

MongoDB, like most NoSQL stores, is hard to maintain, complex to query. To make the same query in the example above may be easy for you but it's not easy for most. You might think, therefore, that you're not the target market. I want to convince you you're wrong. You're going to love this.

First, as you know Schema-On-Need is not just about adding fields on demand but also about changing the mapping cardinality on demand, and then being able to query that in a clear and simple way. That's one of the big changes this query language brings. If you are maintaining a list of Films, you'd be forgiven for expecting only one Director per film, but "Delicatessen" a 1991 French film has two: Jean-Pierre Jeunet and Marc Caro. If you query Film : Director.Name = "Jean-Pierre Jeunet" you'll get that and "Amelie" for example. You'll get all films where Jean-Pierre Jeunet was one of the directors. But if you want only films which were directed by both Jean-Pierre Jeunet and Marc Caro, you would say Film : Director.Name ^=^ ("Jean-Pierre Jeunet","Marc Caro"). Variations of that same operator will give you either one of those directors or films where directors are both but can be others.

The query language also maps very nicely to be used in a BI tool. I'll try to get some examples of that to you, but I think that reason alone is extraordinarily compelling.

The final reason why I think you'll come to love Brodlist will be when you use it. I'm going to make one more analogy if you promise not to shoot me for it. When Google came along, it was just another search engine among hundreds. And explaining the Page Rank algorithm didn't convince many people. But that changed when it was used and the hundreds of other search engines dissipated. My point is simply that hundreds of competitors can reflect not that it's solved, but possibly the opposite: that it's still unsolved. And the other point is that I can talk about it for a long time but what I'm looking forward to most is the chance to prove it to you.

have you looked at cockroachDB ?

Yes, thanks. There's some overlap but I think the Schema-on-Need and new query language are two places, for example, where it strongly differs.

Another hoax?

This comment breaks the rules for Apply HN threads: https://news.ycombinator.com/item?id=11440627.

Please don't do that here, or really anywhere on HN.

Easily the most flattering comment so far. Thanks!

Performant is not a word :)

Much like the word "database" itself wasn't a word until 1962.

No word "is a word" until somebody makes it up. Then it spends some time as a word that people use that isn't in the dictionary. Then it's added to a dictionary.

If you're going to be pedantic, at least choose words that aren't in widespread use and/or have a valid alternative.

It irritates me too (along with a lot of other trendoid jargon) but these newfangled kids here seem to all use it consistently.

Reply on news.ycombinator.com