MongoDB shares jump more than 30% in $192M IPO
cnbc.com
cnbc.com
Undeniably, they did have their fuck-ups in the start, but I think they have done a good job fixing them.
It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer.
It turns out the market for that type of data store. Something you can apt-get install and just start dropping data into is pretty massive. I've used MongoDB on a few occasions. Usually thinking I'm just using it to bootstrap a project, but three years later it's still running because it's just good enough to keep me from moving on to something else.
For example, I used Mongo back in the early days. Was terrible. I will now never use it again. I don't care if it shoots lasers. It is dead to me.
Obviously the happy developer count is way more than the hate it for life count, so I am the odd man out here. Perhaps many users never actually had many GB of data or had to deal with the data loss side of things?
If my boss tells me to use MongoDB tomorrow or live on the street despite my advice to the contrary, I will use MongoDB happily. I may look for a new job in my free time if using MongoDB makes me miserable, but I certainly won't be living on the street...
And quitting your job (as you now point out, but didn't originally) is much different from "choosing to be homeless".
That's a bit too dramatic.
Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem.
Fair point... “I would quit rather than work with MongoDB again” is more accurate, but still encapsulates your point.
The point I was trying to make earlier and did in a way overly dramatic for you is that I’d never take a tech job again if it meant I had to use Mongo.
The high valuation could be an index of the number of failing products happily using the tech :)
I think you hit the nail on the head -- for many programmers who were "coming of age" at that time Mongo was the easiest to experiment with and to get working.
I since turned to RethinkDB and sometimes just a classic SQL will do, but Mongo is really easy to get started with.
That was because it was heavily marketed, not because of timing.
> Mongo was the easiest to experiment with and to get working.
It really wasn't, it was the one they had heard about.
...until it's not. Then it's really not.
I went back to PostgreSQL since. I probably needed a good one-on-one expert training with MongoDB, but I just found myself happier with RDBMS. You don't have to be strict normalization in RDBMS, just enough to make sense for your use cases.
One thing I really did like about MongoDB back then was storing blob (files). It was the best solution available without setting up S3. At the time there was a limitation with 4GB (??) but MongoDB worked for my use case anyway. That being said, please don't store files in any databases today. Use DB to store references to a real object storage like S3. When the DB crashed, you better hope no corruption.
But from my perspective, this is delusional. There is a lot that goes into DBA's experience that is not solved by the performance improvements in databases over the past decade. But there are more choices. 20-30 years ago, you would have been forced to write code on Oracle and you would have asked for help before deciding how to structure the data. Today, with more choices, you just read some online opinions, and jump on it without any internal resource to guide you.
Not saying the world of Oracle was great, but the young on this thread (me included) would benefit from respecting the experience of the old.
Yes, everyone wants "full stack" and so you have a bunch of people haphazardly adorning themselves with the "full stack" label.
I think most of HN would feel this way about, say, Redis. And Redis isn't "highest scale" or "most durable" or "most available" either. (Though it is pretty reliable.)
It's interesting, then, to compare the general impression people here have to MongoDB to the one they have of Redis. To me, Mongo is a "why use it when Postgres is just as easy to install", while Redis is exactly what I'd think of "to bootstrap a project, but three years later it's still running."
Is it just the slightly-different pitched use-cases of "working store" (Redis) vs "persistent store" (Mongo)? Is it that Redis still has its uses even when you've got Postgres there beside it, whereas Mongo doesn't so much (at least since Postgres got JSON columns)?
MongoDB is the best in class at how programmer-friendly it is. Its API is easy to work with. This is especially the case if you are using node and javascript.
The MDB's market cap, i.e. it's valuation, is around $1.17 billion as of the time this article was written:
https://www.cnbc.com/2017/10/18/mongodb-prices-its-ipo-worth...
EDIT: Added 'billion'
Neither of those are true, however.
It is being used by Facebook, Metlife, Expedia, Sony, eBay, Adobe etc.
In what way isn't it ready for production use cases ?
Your parent commenter doesn't like Mongo. So it's not production ready.
Eh I don't like Mongo because I've used it. IDK, it's been a few years since I've had to deal with mongo in a production environment. I don't miss it. I dislike that it's slow to get data to/from the javascript interpreter -- and that the solution was to work around it with the aggregation framework.
I don't like the unsafe defaults (data integrity, access control).
I don't like the magical, unreliable sharding that you have little to no control over.
Sony is a worldwide company with 127,000 employees, they alone probably use just about every database system around. So saying sony uses mongo isn't impressive, for all we know it was just a side project from an intern that has 100 documents, there is no context.
Well I have worked for a number of billion dollar companies who have run MongoDB so there is first hand evidence.
And how is that a paradigm shift? Non-relational, non-SQL databases have been around for a long, long time.
In our economy this is sadly an entirely valid route to making money but their mindshare is going to continue to collapse as the warts on their product show more and more.
So the admiration you have should probably be directed at the wool the marketers behind MongoDB managed to pull over your eyes.
Thats how most products succeed if you ask me.
Let me clarify a bit, I'm not saying that this tactic is invalid or inefficient within our current system, in fact this is a great way to land a good payday if you can pull it off. My point was more that MongoDB is going to implode when their performance shortfalls become visible to the wider populace, if that happens, of course. It's still possible they take the earnings from this IPO and dump heavy into R&D investment to make up the lost ground, but it's also very possible they take this payday and ride out the tech until it breaks down.
As much as I'd love this to be true, the #1 measure of success is if people even know you exist and #2 is if you solve enough of a customer's problems that it's worth using your product. MongoDB hit these two points hard right out of the gate and are now very successful because of it.
Secondly, it’s the ReQL. It’s not native but not JSON based either. A weird hybrid mix.
But it’s only my personal opinion based on my taste.
What Mongo did is implementing these features just well enough so they can put checkpoint in their marketing brochures.
When you actually start using it you learn that most of it is either performing slow, does not work correctly or once in a while corrupts your data.
Yes they hit these points hard, but only from marketing point of view. They are now universally hated by ops and developers because these people now have to deal with fallout.
RethinkDB actually is an example that database is something that's not good as a base for a startup[1], and the Open Source approach (like PostgrSQL) is more suitable.
MongoDB is example that you can base a startup on a database technology and succeed, if you can sleep well at night that your product can cause people to lose data.
[1] The reason RethinkDB failed was because they refused to provide half solutions like MongoDB, everyone expects startup to start making money, but building a reliable databases is not something that's easy and can't be done quickly.
MongoDB serviced one of my projects for 5 years without a single hitch. It did everything I wanted it to do, it did it well, it did it exactly as advertised (no more, no less), and it did it right when I needed it. It never stopped improving during those years, massively in some aspects. The company behind it only grew stronger during those years, and along with it, so did my confidence that my project wouldn't need to undergo re-engineering further down the line.
Seriously, as a professional software developer, what more do you want.
> A RethinkDB employee told me he thought I was their biggest user in terms of how hard I was pushing RethinkDB.
http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht...
It is extremely difficult to do good marketing and sales and they did it.
Solve a customer problem while building a healthy business... a success story in my book.
There is so much work to running a successful business, especially at that scale. Marketing, Sales, Implementation, Support, on top of G&A, and that's not even touching on HR and retaining employees in a competitive market.
There is a reason some people are known as the "business" guys, I think expertise in that area is underrated, especially among people who've only worked at smaller companies or startups.
Edit: Genuinely curious to know why I'm being downvoted. Care to elaborate on why you're downvoting?
Basically I'm in complete agreement with you, and feel this is a hard learned lesson.
A good example is some of the comments that software folks make about the sales department.
They are different skillsets and people have varied abilities in each. The business aspect is not actually easy. It is also not always done well. The software end isn't always done well, either.
My guess would be that is why you were being downvoted. I notice a number of votes are emotional in nature. They aren't based on logic. I see some that are most easily explained as, "I don't want to know." The comment is factual, not confrontational, and topical. The vote is still negative.
Meh... I don't mind it when it happens to me. I have karma to spare and don't actually make comments for the points. I say what I feel needs to be said and try to stick mostly within the guidelines. (I do meander off topic sometimes.)
But, no... I don't comment for the points. I comment for the replies and thoughts. They are usually quite brilliant and insightful.
There are plenty of reasons to write good quality code (it's more maintainable, moves faster, more secure, requires less resources, more fun, etc) but "because you won't be successful if you don't" really isn't one of them.
It's not like they were just a vendor of some other product. They actually spent money on the product, on evangelism (kind of marketing, but also kind of development), on so much.
Stripe's technical achievements at first were basically "a nice button" and a slightly friendlier risk model. Yet they are lauded (as they should be!). We can cut Mongo some slack given how we act about other companies.
To make such an assertion, you're going to have to provide evidence that the people using Mongo and it's services, are, in fact too stupid to know what's good for them, and that they are absolutely better off using something else.
That said, I do think they made a way of handling a data model pleasurable. Different paradigm++
Except that Mongo didn't find success through "simply being successfully marketed". So many people in this thread cannot seem to understand how to look at the business as a whole. Software devs are blasting the software for not being a mind-blowing piece of technology, while not understanding that it has its niche and - apparently - a good business strategy.
You cannot (typically) succeed by only having an amazing product. You also (typically) cannot succeed by dumping millions into sales and marketing for a truly garbage product. The product itself and the business behind it are both necessary elements for success.
There are a lot of developers in this thread trying very hard to appear smart by jumping on the "Mongo is a joke" bandwagon.
Imagine if everyone using MongoDB had to pay for it, you know, like most things in the world?
I suggest they are giving away their cake and picking up a few crumbs after the fact.
Builders don't typically give away homes to sell a few cabinets.
The "product" of a startup is a sustainable business model that can scale fast. The core technology may or may not be a key element part of that model.
So they solved a customer problem with interesting technology - regardless of arguments if it ACID compliant, or as good as <replace with whatever you think is "better">.
Where they sustainable at the beginning? No. Are they sustainable now and did they scale appropriately? Yes.
As a startup that went through it stages, they did it. This is not easy because it requires all the elements to work properly (market need, sales, marketing, engineering, operations, etc).
So what if RethinkDB/or_other has a feature that is better? Irrelevant.
Even better they did this ethically, which is more than I can say about other "startups" with insane funding and dubious and questionable strategies.
I'm not clear on why you think this—software products with huge mindshare and an open contribution model, get their warts fixed, usually by programmers sponsored by corporations repackaging the software (Redhat and Canonical with Linux) or running the software in a SaaS model (Cloudant with CouchDB.)
I’ve no idea to what extent this was true, or if it was whether it was their main marketing approach, but it might have been quite an effective strategy: talks at meetups are often 'trusted' to a greater extent than other ways of reaching devs & if you can find a new generation of devs who are just starting out and hook them on your product before they get the chance to explore other approaches then it could work. High cost of course (someone has to pay for all that time) but if it gets you a leg up on your competitors in a $billion business then that’s what the VC money is for...
However, when it comes to writing software that's meant to survive changes and versions the schema ends up providing a safety net that ensures you can ignore the data that exists and assume that the structure described by your schema is consistent. Data integrity is key to maintainability and those constraints are what keep your data clean.
Makes you wonder what other meetup/hackathon visible tech is really covert marketing...
I actually chose it back in 2010 project and on paper MongoDB looked better than other databases. MongoDB name as they mentioned originates from Humongous Database giving false impression that it can scale well.
They get zero points for this.
It pretty much reads as "Retard"DB in Portuguese, Spanish, and IIRC German.
https://en.wiktionary.org/wiki/mongo
Interesting this isn't the case with English.
https://en.wiktionary.org/wiki/mong#English (Etymology 3)
- "You don't get it, Steve. That doesn't matter!"
It didn't do ACID, not even nearly, but it did other praiseworthy things, with "laser focus on four critical things: onboarding, usability, libraries and support" (https://www.nemil.com/mongo/2.html). Please don't be disparaging about any of those four.
http://scale-out-blog.blogspot.com/2011/05/introducing-mysql...
Don't put down 'easy'. It's incredibly hard to do well.
P.s., I'm DBMS guy and have lived and breathed Jim Grey-style transactional consistency for decades. I'm still impressed by what they did.
Downvoted for this. I haven't used docker much but I just did
> yum install docker-ce
and started the service. took me less than 2 mins.
You ran "yum install docker-ce" you were lucky that you knew the name of the package. I didn't know the name on Fedora, and looking here https://docs.docker.com/engine/installation/linux/docker-ce/... didn't help one bit. Indeed, that page doesn't include a line with "yum" in it at all!
Add MongoDB to the list. Its "good enough", and marketed well.
Well, it's a success story due to marketing, smart marketing, clever marketing, and more marketing, not due to lots of technical merits.
And it was not the first document store to appear, just the most successful. For starters, CouchDB was previous to MongoDB.
We used replication on the native apps for offline mode, kept things simpler with online-only for our web app, and have had a very good time overall.
We are also using JSON schema for our CouchDB documents so we ensure we don't have all kinds of wild / wrong data showing up; if you had really hairy, unstructured data, I can see why a dynamic language might help with that bad situation, but for our use case, we were able to take advantage of the powerful replication built into CouchDB and get solid offline syncing for all of our native apps that also plays nicely with live updates in a web browser.
(Note: I used to be optimistic about NoSQL, but I was dismayed by the extremely low quality that NoSQL products started out at, and stayed at, for a very long time)
Recently I read about Postgres 10 release. Almost all of the features of that are available in MongoDB too.
4 or 5 years ago, MongoDB was bad. But nowsaday the landscape was changed, and I would say MongoDB is quite decent to work with now. It's the easiest database to manage, compare with MySQl, PostgreSQL, ElasticSearch.
Ah yes, the "toss your data over the fence and hope for the best" paradigm.
Truly groundbreaking.
Ive read a Bloomberg story on the IPO and saw there two hilarious sequences "MongoDB has 4,300 paying customers. MongoDB employs 820 people in 29 offices" - that does not compute (for me) so I started analyzing their financial report (btw funny is nobody in whole HN discussion quoted numbers from the report so far, but a lot of 'im buying their stock' talks here).
In the report, scroll to the bottom where they put some cream: they show for last year 91m rev from subscriptions plus 10m from services. While at the same time they show operating LOSS of 85 millions (due to cost, people, marketing, sales, services etc). Khem khem, I know they are growing (holy world) but no, that does not compute.
Of course it is just mine opinion, and looking on the IPO results, rather unpopular one :) but I will stand by it. Especially in next 3 years. Caveat emptor.
I will short them soon.
Note the downside is unlimited when you short via spread betting. Eg, there's no maximum value of a stock, so you might get proper f'd.
It seems like you’re trying to value the company in a manner that doesn’t make sense for this stage of a company, and you could lose a hell of a lot of money.
For the uninitiated in the stock market: you shouldn’t really be shorting anything, especially not growth stocks, and abso-freaking-lutely not immediately following an IPO.
Mongo don't have to be committing fraud, of course. They could be doing any number of actual business activities that make legitimate trades --- but trades optimised at revenue growth, not profitability.
The major metric for companies used to be profit growth. When companies were optimising for that, it was smart to look at revenue growth as a leading indicator. But Goodhart's law ruins everything: now companies know to optimise for revenue growth, and so its value as a metric is much diminished.
I had a look at their prospectus, which describes the bulk of their revenue as subscriptions. Subscriptions sound like good unit economics. It's instructive to compare their pitch to investors to the pitch they make their customers: http://s3.amazonaws.com/info-mongodb-com/TCO_MongoDB_vs._Ora...
When Mongo talk to their customers, they describe the license cost as $0 --- they fold that into support. That sounds more like a service.
In other words: customer fires $100k of staff, pays Mongo $80k in "subscription", Mongo hires $120k of staff, which they tally up as "customer success". There's no expense category for support in their prospectus, so clearly the support personnel are filed under "sales and marketing".
It's the same old story. They're just selling $1 bills for $0.80 a piece.
https://www.hntrends.com/2017/september.html?compare1=Mongod...
That said, it's pretty hard to make sense of when you would want non-relational dbms these days, especially in an era where you can get 100core systems in AWS/GCP. Write-scaling is still a pretty obvious reason, though things like Citus might help here.
With non-default settings[0].
The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system.
The Jepsen tests passed with the "majority" write concern. The default write concern is "1", which means only the "primary" in a replica set needs to acknowledge the write[2]. This does not guarantee safety in the face of network partitions.
It's still not safe out of the box.
[0] - https://jepsen.io/analyses/mongodb-3-4-0-rc3
"With the v1 protocol, majority writes, and linearizable reads, MongoDB 3.4.1 (and the current development release, 3.5.1) pass all MongoDB Jepsen tests:"
[1] - https://docs.mongodb.com/manual/reference/read-concern/
[2] - https://docs.mongodb.com/manual/reference/write-concern/
Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it.
[1] https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.
Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle.
http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...
Personally, I find a non-relational database useful when my data model is non-relational.
This talk is a pretty nifty perf overview:
https://www.percona.com/live/e17/sessions/high-performance-j...
That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
That’s a very naive statement to make.
Absolutely majority of the companies will do just fine, because the hardware improves faster than their demands. Starting out with a distributed system "because one day we might need it" is just silly, because chances are you'll never hit it, and you'll have to pay for the overhead of having a distributed system (which is non trivial).
Actually my company started using PG and had presentation and someone asked if we considered a distributed database so we can scale. The presenter nicely said it was evaluated and this solution worked best, but that was too nice.
1. It's only about 100GB of data
2. The hardware is barely utilized, we didn't tune it (except some standard memory settings), because there's no need yet.
3. Our data is relational (in fact most data from most companies is relational)
Which means you can't use it for any big data/analytics use cases. MongoDB has fantastic client libraries e.g. Spark, Java.
A tree is relational. Each child has a relation to its parent.
I can't imagine data that has no relation (no connection) to anything else. Maybe what you meant was heterogeneous (e.g. data elements that do not all have the same attributes) - but even then I can't readily come up with an example.
Yes, I agree that most types of data can be stored in tabular form (or an "n-ary relation" per Wikipedia). I'm just wondering what concrete types of data one would rather store in a document.
I don't think there is a good example. The decision to store some data outside of an RDBMS must have more to do with the processing model or something else.
What else other than the processing model and business requirements would determine how you model and store your data?
I'd recommend the paper What Goes Around Comes Around[1], the first paper in Readings in Database Systems[2]
[1] https://scholar.google.com/scholar?cluster=73661829057771494... [2]redbook.io
https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...
EAVT is great as an intermediate format but it is absolutely useless to query for since most of the time you are trying to find a set of attributes for a given entity i.e. full table scan.
What you want is a "wide table". One entity column and all the attribute columns to the right. Often with most of the values set to null.
This is the dream use case for MongoDB since it you can ignore sparse values yet when you query it via their drivers it will appear as a wide table. You can't do this at all in PostgreSQL since you will hit a column limit.
JSONB is designed for exactly this, isn’t it?
The lack of a Spark driver alone renders PostgreSQL useless for most companies.
This is what indexes are for. An index on the entity id should avoid any full table scans.
And you want to build indexes on half the table ?
Good luck with that.
Your math is at odds with your own requirements, null values don't need a row.
Sparcity is an issue for the wide table not the EAVT form.
I still can't imagine what sparse heterogeneous data exists in the world that makes sense to store. Any type of querying or processing requires some kind of structure (even if implicit in the code) which you can just put in different table structures.
You have to make sense of data to process it and that kind of implies a structure, doesn't it? Am I missing some obvious example of heterogeneous data?
One customer column, tens of thousands of attribute columns.
If you need everything about a customer it is a single, O(1) fetch operation which makes it perfect for driving chat bots, call centres, websites, operational decisioning engines, dashboards etc. Almost every large company will have one of these.
You can't really do it in relational systems properly because (a) you hit the column limit, (b) often it is sparse i.e. lots of NULLs everywhere, (c) you need this system to be distributed since it often gets a lot of load.
But where you get into tens/hundreds of thousands is when you have machine learning models automatically selecting and storing important features from the data.
In years past, people called these "data warehouses" and essentially took snapshots of their production DBs and denormalized the hell out of them so that aggregations wouldn't crash the server.
Try modelling a cyclic graph in a relational way and you'll quickly tie yourself in knots trying to update and query it.
The point is, relational databases a great for storing data that you've decided to model relationally. If you decide not to, then you probably want some other sort of database.
Sure. But that database is not MongoDB.
The "you only need relational databases" mantra bugs me though, because it's so obviously not true.
I bet two years ago there was someone out there saying "if you're going to do NoSQL you better use RethinkDB over MongoDB"
How great the technology is, is absolutely not the only factor. Good thing people can take in many different factors when making their decisions.
Most RDBMSs can do key-value stores very well now. Most applications also care more about consistency over availability, which is what RDBMSs do (CAP theorem). Many NoSQL data stores choose availability and partitioning and sacrifice consistency (i.e., "eventual consistency"). There's a lot of applications that you can't sacrifice consistency for. Electronic health records, financial records, student records, employee records, etc. You care that the data are accurate and up to date, and you want the system to error if it can't provide that. Wrong answers and "close enough" answers aren't good enough.
Now, if you're running Reddit or Wikipedia or Facebook or HN... do you really care if a user doesn't get the absolute latest version of a document or comment? No, not really. If the content is hours old it's a problem, but it's not a big deal if it's a few minutes out of date. You care more that your users get a version of the document more than you care that they get the latest version of the document.
But "applications" are built by development teams.
So: Does an "RDBMS makes sense for most applications"?
EDIT: If you downvote, please explain why. You can't disagree with the truth.
Although I kind of got used to RDBMS crowd not understanding consistency, it's just another technology cult.
https://docs.microsoft.com/en-us/sql/t-sql/language-elements...
> If the transaction committed was a Transact-SQL distributed transaction, COMMIT TRANSACTION triggers MS DTC to use a two-phase commit protocol to commit all of the servers involved in the transaction. If a local transaction spans two or more databases on the same instance of the Database Engine, the instance uses an internal two-phase commit to commit all of the databases involved in the transaction.
I'm only versed in SQL-Server but I'm pretty sure other RDBMS vendors provide similar functionality.
At the single server level (which is how I think others here are interpreting your comment)? No, they all do, with the exception of some configurations of MySQL (especially older editions, which is why it's often maligned by DBAs). That's what transaction logs do. They're literally a write ahead log (WAL). You commit a transaction, and the DB first obtains an exclusive lock on the affected rows (or page, or table). Any other transaction attempting to read or update those rows will be blocked (with exceptions). It then writes the change to the transaction log and flushes the change to disk. Then it writes the changes to the database file and flushes the change to disk. Then it returns the results of the query to the user. Many RDBMSs let you control how tightly the locks are and the degree that the data are isolated during a transaction.
At the distributed network server level? Then I guess I kind of agree with you, sure. RDBMSs let you "get around" the problems of distributed scaling by not letting you do it easily. SQL servers often only have master/slave or publisher/subscriber setups or otherwise partition the data between instances with sharding. There's no need for raft or paxos type algorithms because they don't attempt to implement a true multi-master environment. There's either a fixed overall master, or each server is the deterministic master of it's own little world, so you avoid consistency problems with distributed data. However, in doing so you sacrifice availability, since if a shard goes down so does all that data, or if the master is busy then you can't always submit queries to the slaves. Replication is used for redundancy, not scaling or load balancing. The solution RDBMSs had was sharding + master/slave replication for redundancy, which can get messy fast and has issues like hot spots or limited queries or variant performance. It's just a lot harder to do than it feels like it should be, and with storage as cheap as it is it feels like a waste of effort.
That said, some RDBMSs do allow you to use multimaster, bidirectional, or peer-to-peer replication, but most of those configurations basically warn you that you're sacrificing consistency by doing it and all of them that I've seen are a huge pain in the ass that makes shard + replicate look like child's play. They also have schema requirements that make life difficult, and they're somewhat notorious for being difficult both to administer and develop for. You have to design the whole thing from the ground up to work with this type of replication, it still feels like a house of cards, and it's this exact level of pain in the ass that encouraged the partitioning and availability focused NoSQL data stores.
However... most applications don't need that kind of scaling. They don't need a database in every time zone for single millisecond response times globally. They don't have the users to demand it, or don't have the quantity of data to require it, or have other requirements that make a traditional RDBMS desirable where you can't accept a system that allows for out-of-date data (which is when PACELC theorem kicks in because NoSQL typically doesn't have locking like an RDBMS does to mitigate this particular problem).
Google’s Cloud SQL is a good example of that, by using TrueTime as transaction id, and an MVCC implementation, they are able to provide consistency, while also being good enough on the other metrics.
Some NewSQL implementations copy that concept, but unless you run GPS clocks yourself, you’ll get slightly worse results.
Yep, all of MongoDB is just one bullet point on Postgres's list of features. Anyone spending on money on it ought to be hauled before the shareholders and given a talking to on fiduciary responsibility...
Tell me again how Postgres can seamlessly do horizontal scaling and synchronous replication?
[0]: https://www.2ndquadrant.com/en/resources/pglogical/ [1]: https://www.2ndquadrant.com/en/resources/bdr/
In general Postgres was not designed at its core for a distributed world. Even now, replication feels like an afterthought in the grand scheme of things, and sharding nonexistent without extensions.
> MongoDB’s version 0 replication protocol is inherently unsafe.
Tell me again how MongoDB took 8 years to get to the point where its replication is kind of OK.
I'm very curious about what people think about the future of Mongo, independently and particularly in comparison to Postgres. However every time that comes up, people keep bringing up that Mongo was a buggy piece of crap in some irrelevant past. So what?
8 years ago PG did have replication though, so not sure why it not having feature X 8 years ago makes my point moot.
People keep bringing up that it was a buggy piece of crap because its the icing on the cake and pretty much something you never want your database to be, past or present. Not that software configured by default to eat your data and not persist it can be called a database mind you.
Of course I would prefer Postgres when I can use it, and I can generally use it basically all the time, but NoSQL still has its use cases.
I mean... do you? I often come back a few minutes after posting to add something I forgot or rephrase something for clarity. I hate when I am tweaking a Reddit comment a couple times during a period of high server load and I get served an old version of the comment and end up losing something I added in a previous edit.
With something like Wikipedia it would be quite frustrating to lose revisions.
Obviously it is what it is, I can't change their codebase, and I'm sure it's necessary as currently engineered, but is there really no other way to cluster their data except "one big table"? Maybe like shard subreddits to specific servers ala Hyperdex?
But yeah, most places that Mongo is applied aren't exactly Facebook or Reddit either, in terms of total data throughput.
Data stores like Cassandra and MongoDB don't lose revisions. That's not the kind of consistency we're talking about. CAP consistency is just getting the most recent version. You won't lose data -- data loss is a bug, not expected behavior, just like any other data store -- you just won't always get the most recent version of it. And, keep in mind, when we talk about eventual consistency here we generally mean "consistent on all nodes within a few minutes, but we're not blocking reads to write this data." It's not going to take hours.
That said, if you find you get an old version of your own comment, I'd be more willing to believe it's the fact that your request failed with a 503 error or otherwise timed out as much as it was a data store problem. Next time it happens, wait 5 minutes and try again.
> is there really no other way to cluster their data except "one big table"? Maybe like shard subreddits to specific servers ala Hyperdex?
The whole point of MongoDB or Cassandra is that you can get shards without all the headache that RDBMSs usually put you through. You configure your sharding function and let the system do the rest. You don't have to connect to the right shard or anything of the sort, which some RDBMSs do (or did, it's been awhile since I've looked) require with sharding.
Reddit has their code and architecture posted, though it's out-of-date now, it makes it clear that it's basically just two big tables:
https://github.com/reddit/reddit/wiki/Architecture-Overview
It's PostgreSQL, ThingDB, Cassandra, memcached, and RabbitMQ.
Why? An RDBMS has never been the best option for any application I have created and I have created standard business applications as well as consumer applications.
Wikipedia uses MariaDB (so, MySQL). https://meta.wikimedia.org/wiki/Wikimedia_servers#Software
While you're at it you could also elaborate on why Postgres is much less "solid" than a database that literally eats writes without any consensus as to if they are valid and/or actually written. After that you could explain why "post-cap" is a thing.
Until you do, your comment is pretty useless and it sounds like you could do with a nice shot of consistent, well designed database right to the heart.
I see it as the founders needlessly missing out on 30% of money (in this case), which ends up going in the pockets of the Wall Street middle men that get first access to the stock offering.
- For better or worse, a pop is seen as a successful IPO. A lot of the market is about expectations and if you have an "unsuccessful" IPO you are going to get good press.
- Underwriters are selling to the same institutional investors over and over. They're going to promise those investors that there will be a reward for getting in on this IPO. If an underwriter sells a bunch of IPOs that don't go anywhere they are going to have trouble continuing to underwrite
The first point amounts to one good press cycle. You can get that other ways and the lasting value of a single cycle of fluffed up good press based on underwriters and their cronies making money on their shares is nil.
The second is entirely the underwriter's problem. A company only IPOs once; there's no reason for them to take a hit to help the underwriter and friends make money for no reason. The underwriter takes a cut and a fee regardless.
Think of it as an additional cost of underwriting just broken out in a weird way and it might be more palatable.
If you want a lot of interest in your IPO then you probably need underwriters with big institutional relationships. The underwriters with the best relationships are going to be the ones who help their clients get good returns. You're just paying for better underwriters by losing part of the pop instead of paying them fees directly.
Companies are free to go to smaller underwriters in exchange for an IPO price that's closer to what the underwriter thinks the market will bear. And yet most of them choose not to.
Given that almost every IPO has a pop, what do you think is most likely
* CEOs & VCs taking their companies public don't realize that they are leaving money on the table by underpricing the IPO. You have two groups of sophisticated finance people and the underwriting side always manages to fleece the company going public.
* There are structural reasons and incentives for creating an IPO pop
You can't even accuse people of trying to fleece the low-level employees and retail investors. The employees are locked up either way and whether you have a pop or not, by the time the shares reach the retail investors they're the same price either way.
That's the system as it's currently implemented, yes. Underwriters have some folks on tap that they'll let in on the IPO. IOW, folks that'll dump money into the IPO. But those folks aren't suckers, they'd like to see a return on their investment, if not individual investments then at least in aggregate. So, in summary:
1. Companies want someone to buy their new shares.
2. Brokerages have such folks on tap.
3. However, those investors wants a return.
4. So the underwriters set the IPO price a bit low so as to increase the chances of investors getting that return, which means those investors will come back next time for, say, pets.com's IPO.
I doubt this is written down anywhere, but that's the impression I get from observing IPOs (tech and non-tech) for 20 years or so.
If it was done on the highest price - then those investors who are buying after IPO would have put in bids in the IPO and there wouldn't be a pricing gap.
That said, the goal is for shares to have a nice upward pop when they hit the open market.
This helps encourage a broader based of shareholders, protecting against the case where a big shareholder decides to dump all of their shares.
This also helps in the case where the company comes out with bad news in the near future. Shareholders who make money are less likely to sue.
Auctions can work pretty well for pricing things.
If you IPO at 24 and it jumps to 32, hopefully it is still 30 when you can sell. If you IPO at 32 and it drops to 26 cause there is no buzz, you make a lot less when you sell.
An IPO that goes up instead of down is much more likely to attract more investment thus driving the founder's remaining shares up.
I didn't go in that big, but we will see. I bought 700 shares at $29.12, sometime around noon. I was a bit busy so didn't pay much attention to this thread, but they closed at a bit over $32.00.
I haven't yet set a mark to sell them. I do have it set to notify me I'd they go below 29.00 and will sell them all if they go below $24.00. Ideally, I'll keep the shares for a full year, at minimum.
I figured 20k isn't too much to risk, though I technically risk less than that because I will sell if they go below $24.
So, we shall see... We shall see... It is one of the rare times when I am betting against the folks on the tech forums. The commentary seems to be largely negative, concerning the software itself - I've never personally used it. I'm betting that the hype train will continue, regardless of it not being perfect in every way.
I did the same thing with Tesla, though they were $24 at the time.
I've written about this before, here in HN comments. I often make stock choices based on the commentary at sites like Slashdot and HN. No, I don't listen to people saying to sell or buy, I listen to the hype and commentary about the companies themselves. As another example I did well with Yahoo!
To be clear, this isn't serious money. I have someone who professionally manages my finances. This is more an experiment and is meant to to play around.
I know, that probably sounds a bit terrible. But, it's not money I am worried about losing and I'm actually doing pretty good at speculating. I make greater returns than the person who does it for me - which is to be expected. I take a bunch of risks, don't do traditional research, and don't even check the daily prices.
That way, I can change my mind if, for some reason, I think it will rally.
I do another one and someone told me there's a technical name for it. I forget the name.
When I go shopping, I'll discretely look in shopping carts. I'll make a mental note and check to see how well the shelves are stocked in comparison to other products. If I see a lot of the same company in carts, to the point where the store hasn't matched stocking well, then I'll look further into the parent company.
So far, it has done well. I'd never played in the market before and my 401k was always managed. So, this is pretty new for me. I've been at it since maybe 2011.
https://opensource.google.com/docs/using/agpl-policy/ https://github.com/mongodb/mongo/blob/master/GNU-AGPL-3.0.tx...
It looks like all of the drivers you would use to connect to it are Apache 2.0 licensed so that wouldn't be a reason.
Microsoft, IBM, and Oracle are legacy technology companies? What kind of hipster journalist wrote this article?
Does this just seem like it can't be true? Does anyone know where or why this would be the case?
I have no idea what his sources were for this, but it signals Mongo's marketing power to me if a non developer would become so avid about it.
It's the only truly working example of a horizontally scalable arbitrary document storage and retrieval system with indexing on any element. It is a much more general tool then an RDBS, and should never be used when an RDBS would do the job.
However, it's really good at collecting searchable, arbitrary schemaless data in real time. The newest versions do what they're supposed to do rather well, it's a tool like any other tool.
That said, the company is guilty of overhyping for sure, and I wouldn't invest in the stock on a rational basis.
The hate comes exactly from that. The "hipster" just use it for everything. Try reading some "modern" webdev tutorial without seeing it used wrongly.
(Full disclosure: PM at MarkLogic)
A quick look at your web page tells me why. You have no open source or free version that I can download and kick the tires of.
And the reason for them being non-defaults is that it will drastically reduce performance.
Edit: Also looks like Kyle saved for the next time testing of server crashes and restarts which is another difficult problem to handle when performance is important.
They also fail the VC "rule of 40" where SaaS companies should have growth plus margins equal to 40%. (50% growth and negative 10% margins, or 10% growth and 30% margins) They seem to be at 50% growth, but minus 40% margins.
Somehow they pulled it off. Great for them!
Only Hadoop probably has an even bigger name. That's what everyone connects with machine learning and AI, so every big company needs a Hadoop cluster.
SQL is just an interface, obviously common to relational databases but can be applied to any datastore. Spark/Drill/Presto/Dremio/etc can give you SQL over any data, even just files in a folder somewhere, so let's clear up this notion between actual database technology and the access path.
Document stores are definitely useful. MongoDB is one of the better ones today although it had a rocky start. RethinkDB was an interesting experiment but never matured, RavenDB is a solid contender, Couchbase has proven itself, Riak might stick around, and there are dozens of others.
There is a place for everything and MongoDB is being used by plenty of companies to great extent. It might not always be the right choice but when it is, it works incredibly well. Good luck to the team, I'm glad to see the success in both the product and the company.
This is not at all correct. SQL has well defined semantics that are standardized around the relational model and ACID guarantees. A nosql datastore is one that intentionally makes tradeoffs that force it to deviate from that model. The name makes sense if you understand that SQL was the first broadly adopted language that targeted the relational model.
I'm not very familiar with the systems you mention other than Presto. But if they do not provide relational guarantees then even if they have SQL-like syntax the semantics are sufficiently different for them to not be implementing a true SQL. Hence, nosql.
Relational databases have a history of offering both in a single package, but there is no "true" SQL. There are also plenty of non-relational data stores that offer SQL and/or ACID guarantees so this limited generalization isn't accurate or useful.
"NoSQL" has no meaning other than originally describing systems that did not have any SQL access at all, usually due to different storage layers, distributed architectures, custom access protocols, and general immaturity around usage. A decade later, all of these systems have evolved and there's both convergence and specialization everywhere.
It would be far better to just talk about the actual type of database, and the interfaces and guarantees it provides, rather than marketing jargon like nosql.
The difference between and O( n log n) algorithm and an O(n^2) one could have made the difference between a decent product and a totally unusable one.
Nowadays, toy examples can seem to work fine even when the products have really terrible implementations.
They promise that it's so easy to use you don't need a DBA, you don't need any ops staff to run it, etc, just develop and go! Then once you're in too deep, they get you...
Seeing the comments in this thread, it's interesting how it gets compared with PostgreSQL. People are missing the point — NoSQL only happened because of horizontal scalability requirements, being the number one reason for why people want NoSQL.
Just because PostgreSQL can now store and interrogate JSON, that doesn't mean that PostgreSQL can scale horizontally. In fact PostgreSQL sucks at horizontal scaling, historically its replication story has been worse than MySQL actually.
And might not have big data, but you might want redundancy and scenarios with pretty tight SLAs are not uncommon at all.
It's like a weird version of the Turing test where you have to decide whether someone's speaking seriously or in jest when they talk about NoSQL.
(Is that the same idea?)
But recently, I've been exposed to a fairly big and complex SQL one with several references between entities and lots, lots of X_has_Y tables. This makes me think that with growing complexity (which seems to be a general trend), NoSQL databases seem more practical at some point, or at least something less rigid than classic relational ones. I'm not saying SQL is obsolete, but it seems like its domain of usefulness is shrinking.
Meanwhile, Postgres was quietly plugging away adding new features and continuing to deliver solid performance for a wider range of workloads, including better performance on JSON document storage.
Even at its best, there is essentially no reason to choose MongoDB over Postgres with JSONB-type columns. They are essentially the same data model but Postgres gives you better guarantees of data consistency, plus a forward migration path to relational data when the day inevitably arrives when you need to model relationships between entities.
At this point Postgres is where most open-source RDBMS development work is concentrated. It's not only a solid codebase, it's piling up features pretty quickly and there are relatively few niches it doesn't fill at least adequately. All of these niches are covered by some commercial products built on top of Postgres (eg EnterpriseDB or CitusDB). It's pretty much a one-stop shop for application development. You can use it for everything from GIS to machine learning [0] pretty efficiently, and it pretty much will just do the right thing without you watching.
NoSQL really fits best around the margins, like as an auxiliary system for analytics. There is really almost no use-case where "user inputs data and we lose it" is an acceptable application behavior, so consistency is a business requirement for your master database whether you realize it or not. And consistency across a distributed system is hard so it almost always makes sense to sidestep clustering until the last possible moment. Buying more machine is cheap, replication/failover is a lot easier than consistency between distributed masters, and if you are really up against the wall there are those commercial products that can do this with Postgres.
If you want to make an analogy... Oracle is the suit, Postgres is the hardworking small business that is slowly but surely eating up Oracle's lunch, and MongoDB is a trustafarian with a hot-dog detector app. And that's why there's a lot of resentment towards MongoDB.
[0]: The 9.x series and 10.0 release have been absolutely jam-packed with new features, it's absurd how fast development is moving at the moment. One of my favorites... indexed cube queries. A cube is a data-cube type, an N-dimensional cube of data. One feature of this is distance queries, which have obvious applications in pattern recognition tasks (eg k-nearest-neighbor). One of the features in 9.6 is index functionality for these, so you can now do indexed KNN searches on your data...
https://www.depesz.com/2016/01/10/waiting-for-9-6-cube-exten...
I'd say it also fits well in two niches: document datastores (so long as there's some JOIN support, via referencing nested documents vs direct nesting) and graph stores.
I remember 10+ years ago working on storing nested sets in the RDBMS and it wasn't pretty. And the RDBMS schema for Magento 1, with key-value tables all over the place which NoSQL would have removed the need for.
Which has its own problems. PG does this just fine, with a full battle-tested relational system to back it (and you) up.
> with key-value tables all over the place which NoSQL would have removed the need for.
Product X having a stupid schema is not a good basis for an argument for or against a particular product.
What other way could Magento have implemented user-defined columns at the time, using a RDBMS? In 2009 when MongoDB was released, JSON columnstores were something to dream of and the alternative was storing serialised data in a BLOB field. That "stupid schema" did not have an alternative I can think of, except NoSQL.
Postgres supports hierarchical/nested structures using the "ltree" column type. There is nothing stopping you from defining a primary key of (eg) "set1.set10.set100". There is also support for recursive views/etc to operate on these kinds of sets.
Again, if you have some kind of "sparse" column, it can make sense to put that into a JSONB column. This is effectively the same thing as attaching an unstructured document to a record for this use-case.
Joe Celko popularised them. I've been unable to find when they were first introduced; but a search of my source code archive points to having written one ~14 years ago.
I'm pretty sure that mmap was the only storage engine available for MongoDB for most of the hype period.
I bet they are still waiting for that join....
If I’m doing analytics on a time series this gets even better with partition pruning and hash joins or bitmap indexes. And if I have a columnar database, that blows up this whole complexity argument.
My point is that, layout and indexes should never be assumed to be one size fits all. Keep in mind if I’m doing analytics I want to bring my time series data into memory at least as a stream, as I need to calculate / filter / transform the records. Not everything is about rendering a page on a website.
Interestingly enough, many of those techniques are common in the NoSQL world as well — a billion records is enough to require thinking about data flow anywhere — but the difference is that you have to deploy them more frequently.
Less rigid than what? The schema is going to exist somewhere...
Most other models are for high performance of specific access paths and punt integrity management to code, which is a throwback to the 70s. They’re glorified file systems and data structure caches. Mongo has a reputation for losing your data.
There are cases where scale and availability kills you and you need something like Cassandra or whatnot. But there are few as flexible and general as Oracle or Postgres.
Not entirely true, but nuance often precludes persuasion.
Many of the ideas behind NoSQL databases can be very valuable, given the right context, but there are a lot of good reasons relational databases have been the de-facto default over the last four decades.
https://en.wikipedia.org/wiki/Poe%27s_law is the term you're looking for...
So that said, when comparing NoSQL solutions, ending up with an apples versus oranges comparison is almost inevitable.
The number one reason for why people want NoSQL is horizontal scaling and for that PostgreSQL is terrible, with all available solutions being hacks that don't work.
I would refer you to an earlier comment:
> In general NoSQL solutions are optimized for certain use-cases at the detriment of others
Your definition of 'right' is absolutely not the only definition of 'right'.
More to the point: there are a lot of problem spaces where the data integrity provided by MongoDB are more than sufficient.
Define tons of data. I'll bet a beer that what you say can fit on a single postgres instance and even be small enough to run fine on a cheapish developer laptop.
Sure MongoDB may not be the best fit for it but my point is more that these are scenarios where horizontal scaling is an important consideration makes more sense for some nosql solutions than for sql solutions. It's not just about single box performance.
Remember, sharding isn't scaling the database. Sharding is admitting your database can't scale so you're offloading the problem to another layer.
But more common than not, inexperienced devs are using Mongo and similar to store relational data, simply because they were sold the 'MEAN' stack and didn't realize that, while it's easy to get a quick prototype running, a year or two later you eventually need things like transactions and joins, and NoSQL is absolutely the wrong technology most of the time.
But I do think http://www.scylladb.com/ is great.
There was a post on LinkedIn last year, "MongoDB: The Frankenstein Monster of NoSQL Databases"[0], by the CTO of SlamData, which I think produces an analytics package for MongoDB or the like.
The piece is an interesting dive into why MongoDB is what it is (at least as of March 2016) -- and given his connection to MongoDB and its employees -- being a partner of theirs -- it's quite eye-opening (and I'm surprised with almost 200 comments in this thread that no one posted it previously):
Much like Mary Shelly’s Frankenstein monster, MongoDB’s data access layer is sewn together from ragged pieces that don’t fit together. Pieces that were never designed to fit together.
The result, depending on your point of view, is either an Enterprise-grade NoSQL database destined to supplant Oracle, or an unholy abomination of nature, deserving of an angry mob bearing torches and pitchforks.
Let me dissect this creature so you can decide for yourself.
[0] https://www.linkedin.com/pulse/mongodb-frankenstein-monster-...
You might expect a database company to announce improved scalability, reliability, or performance. Or perhaps announce some of the countless features that users have been requesting for years, which are collecting dust in MongoDB's ever-growing issue tracker.
These are sane, logical expectations for a database company, so you'd be forgiven for being shocked at MongoDB's announcements that the company is investing massively into every product category except database technology.
Yet, to those who know MongoDB's troubled history, these announcements come as no surprise. In fact, I even predicted the launch of Stitch just over a year ago, at the last MongoDB World.
MongoDB didn't start as a database company, it's never acted like a database company, and in my opinion, it doesn't really have the DNA of a database company.
If his assessment in this next snippet is correct, one wonders about those who invested in this IPO:
MongoDB has no ecosystem. There are no analytics tools for MongoDB (except SlamData [N.B. this is the author's company] ), no backup software, no recovery software, no data integration software, no query optimization software, no data management software, nothing. Zilch.
There's just MongoDB.
In hindsight, this is an inevitable consequence of a company without database DNA trying to build and monetize a database. MongoDB couldn't figure out how to build an Oracle-sized empire on a database—partially, I'd argue, because they couldn't figure out how to build a database—yet they have to hit their sales quotas.
If you can't sell the database at scale, you end up trying to build and sell an ecosystem around the database. Slowly, bit by bit, MongoDB went after their early partners, trying to put them all out of business to drive a few million here and there.
The result is a "database company" that sells everything under the sun, including database management tools, data exploration tools, cloud hosting tools, cloud hosting services, and soon, BaaS (Bubble makes a return!) and BI software. Everything except, you know, a database.
[0] https://www.linkedin.com/pulse/mongodb-world-2017-lonely-sto...
The development community doesn't seem to care about fixing bugs, and when they do fix things, they reliably introduce new, often devastating defects. "Move fast and break things" is unforgivable at the persistence layer. We're stuck using an ancient, unsupported version, because it is, per our empirical testing, the least bad. But we made that choice, and for now we're stuck with it.
Please, let our pain be a lesson to you. I am totally willing to be someone else's "That's how you get ants..." on this point. Our emoji for it in Slack is a burning poo. It's that bad.
EDIT: phrasing.
Which is this least bad version, if you don't mind my asking?
You say you're stuck with it. Can't you just change a few things, shut down for a little while, export your data, and insert it into a new DB? I know it is hard to do it with writes happening at the same time, but it seems like you could freeze it as read only, extract the data, and put it into a DB that has been prepped ahead of time and tested.
I know we did this more than once BUT it wasn't with public facing data and we were able to migrate while still working on existing data. We just couldn't add more data while doing so.
The issue I've found with the sync gateway is that the queries you can perform are more limited than what you can do directly on a Couchbase store e.g. joining data is difficult.
BTW, Couchbase should not be confused with CouchDB. Similar name and might have some history in common, but Couchbase is more fully featured.
In this context: please, for the love of God, improve your documentation and dev tools. I love the underlying technology but my experience getting a basic service up and running has been pretty mixed. One of the reasons mongodb has been so successful is that there's 50 bajillion articles showing you how to hack up some crappy code that roughly does what you need it to do. Some of those articles are less bad than others, but in a pinch you can find something to at least get you on the right track. Couchbase doesn't have that deep well of experience to draw on. If you run into a problem, or experience strange behavior, it's up to you to figure out what's going on. That would be ok, but even the official documentation and standard dev tools are not good enough. To get people to adopt couchbase you need to do more to get them started.
Javascript-specific whining: it's particularly frustrating to find an official ODM like ottoman and discover that half the features don't work and that there are tons of bugs that haven't been fixed for about a year. These aren't minor bugs either; some of them stop you using headline features. Forget full text search, N1QL is mostly unusable! Check out ottoman bug #153 for details there.
(I use sublime..but I admire those who've jumped into vim for the productivity boost that brings).
Let's scrap everything that was invented in the 70's or before.
Edit: Honest to god question. I was surprised when I saw the headline, because I've never seen anyone use mongo in production, and never ran into any articles talking about using mongo.
For something like your typical rails app, Mongo has some real nice properties. It makes it sticky. You start out with Mongo because you can just drop data in and off you go. You keep using it because Mongo, despite all of its drawbacks, is really plenty good enough for more than 80% of the stuff on the web.
Do they have growth at a rate that justifies their valuation?
If that's the case, is HN living in its own bubble? Because if you read HN you'd think that nobody will use mongodb for a new project.
The main point is: most of your data is most likely relational and not document based. Use the DB that fits your data model, and not the data model that fits your DB.
https://www.percona.com/live/e17/sites/default/files/slides/...
[1] https://www.sec.gov/Archives/edgar/data/1441816/000104746917...
1. Spot a non-trivial expense type applicable to most Fortune 500 companies.
2. Make a startup offering the same thing under the cost.
3. Use your network to get sales people that personally know exec-level people from Fortune 500 and will pitch the product to them.
4. Get them to sign up. Of course they'll do, you're offering it under cost at the investors' expense.
5. Show impressive revenue and customer base growth and forget the word "profitability".
6. Make an IPO and cash in before the public realizes that your might have been selling dollars for ninety cents.
Who's left holding the bag? Average Joe, who's pension fund ended up investing in a promising technology company showing exemplary revenue growth over an extended time period...