
Amazon DocumentDB, with MongoDB compatibility - ifcologne
https://aws.amazon.com/documentdb/
======
ahachete
My bet is that it is built on top of Aurora PostgreSQL. By looking at the
"Limits" section
([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/limits.html)),
identifiers are limited to 63 characters and the same characters that
PostgreSQL limits identifiers to; and a collection size limit of 32TB,
coincidentally maximum PostgreSQL table size.

Edit: I can confirm: does not allow the UTF-8 null character in strings:
[https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/functional-
differences.html) ... It is written on top of PostgreSQL.

~~~
erikig
It would be nice if Amazon provided an API to access the data via SQL
alongside the MongoDB API; I've seen quite a number of organizations migrate
from mongo to Postgres once they get out of the rapid development phase. This
would make that transition butter smooth.

~~~
scarface74
Anecdote:

I led a C# project where we could seamlessly switch back and forth between
Mongo and SQL Server without changing the underlying LINQ expressions.

We sent the expressions to the Mongo driver and they got translated to
MongoQuery we sent the expressions to Entity Framework and they got translated
to Sql Server.

~~~
manigandham
C# is ahead of the game with LINQ, expression syntax, and the entire Rosyln
platform. Passing an IQueryable<> around that can be interpreted and
transformed for multiple backends is a incredibly productive. I wish more
people knew about this, and .NET in general.

~~~
scarface74
And I’ve seen a few Java and Javascript libraries that purport to “implement
LINQ” and they don’t get the power of LINQ is not the syntax, it’s that LINQ
translates your code to expressions that can be parsed and translated to any
back end query - it’s not just an ORM.

I’ve seen a LINQ to REST API provider.

------
abrookewood
I was reading a post [0] by Brian Cantrill that predicted this would be the
result of licences like the SSPL. I instinctively disagreed with him, but it
turns out he was right: "The cloud services providers are currently
reproprietarizing all of computing — they are making their own CPUs for crying
out loud! — reimplementing the bits of your software that they need in the
name of the service that their customers want (and will pay for!) won’t even
move the needle in terms of their effort."

[0] [http://dtrace.org/blogs/bmc/2018/12/14/open-source-
confronts...](http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-
its-midlife-crisis/)

~~~
dman
What is the way out? Would love to hear from people.

~~~
Lazare
Ultimately, Cantrill put it well:

> ...for those open source companies that still harbor magical beliefs, let me
> put this to you as directly as possible: cloud services providers are
> emphatically not going to license your proprietary software. I mean, you
> knew that, right?

MongoDB Inc cannot make Amazon pay commercial license fees. That is not a
thing that will happen. They have a lever in front of them with two positions,
one of which is "large cloud companies might use your software for free", and
the other is "large cloud companies will not use your software at all". They
didn't like the first option, so they gave the lever a yank, but they're not
going to like the second option, and there is no third option.

The way out is not to try and build a business on the assumption that people
who have no interest, requirement or reason to give you large amounts of money
will inexplicably do so anyhow. :)

This thread already has people eyeing up DocumentDB's pricing and comparing it
favourably to MongoDB's competing Atlas service, and it's almost unthinkable
to suggest that Atlas can compete on price _with Amazon_. The way to win this
game is not to play; the rules are not in your favour.

~~~
meddlepal
Could Mongo or other companies use the Oracle v. Google precedent regarding
API copyright to extract money from competitive vultures like Amazon?

~~~
naner
Oracle are the good guys in this scenario?

~~~
spullara
They always were the OK guys in that argument. Google invented a whole new VM
and bastardized the language just to get out of a $1/device licensing fee for
mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its
lack of support for more modern versions of Java.

On another note, anyone that doesn't think API design is a creative endeavor
and worthy of protection probably has never made a great API before. It may be
OK to accept that and also let other people use the API for free but I think
ruling that it isn't is BS.

~~~
elygre
I also always found it amusing that people thought API design was not creative
and protectable.

Like, “how many ways can you do a date api”, and then turn around to look at
the original java Date api, the Calendar api, JodaTime and JSR310.

~~~
int_19h
An API is just a collection of facts of the form, "if the system gets input X,
the system produces output Y". And facts shouldn't be copyrightable.

~~~
deanCommie
You could describe inventions as "facts" too, are you saying that inventions
shouldn't be patentable as well?

Maybe the fundamental properties of the universe aren't
copyrightable/trademarkable/patentable, but what you CHOOSE to do with those -
what API you design or what widget you build out of it certainly is.

~~~
int_19h
Patents and copyrights are two very different things, though. I don't know if
APIs are patentable, but that's a very different question. Has anybody ever
successfully patented an API?

------
ISV_Damocles
Now I kinda hope Oracle decides to buy out MongoDB and integrate it into their
own cloud. Then Oracle can decide to pull the same bullshit that they did with
Google over the Java APIs with the MongoDB APIs but now against their current
enemy Amazon (and Microsoft, too).

Then a combined Google + Amazon + Microsoft may finally be able to reverse the
API Copyright insanity that is hovering ominously over the tech industry, and
Oracle can continue to be a shining city upon a hill of shitty technologies
you should never allow your business to adopt.

~~~
wmf
AWS is preemptively defensive about API licensing claims: "Amazon DocumentDB
implements the Apache 2.0 open source MongoDB 3.6 API".

~~~
christkv
I think they are referencing the drivers which are licensed under Apache 2.0.

------
buremba
I don't understand why people are reacting to it so aggressively. That's
basically how AWS works, they did the same to Apach Kafka with Kinesis,
Prestodb with Athena, PostgreSQL and MySQL with Aurora, Redis with ElastiCache
and many others over the last 4 years so it's not new.

It took too long for the open-source community to figure out that the cloud
providers are killing them, now it's too late. Well played, AWS.

~~~
driverdan
> It took too long for the open-source community to figure out that the cloud
> providers are killing them

How are service providers killing FOSS? That doesn't make sense. Permissive
FOSS licensing allows anyone to use their software, regardless of how it's
used, and that's how it should be.

~~~
keepper
Do you get to see AWS's source code for these services?

No...

That's how it's killing "FOSS". Extend and Extinguish. This is not a new
playbook.

~~~
SilasX
I don't think you get to see MongoDB's source code for the enterprise edition
either (though I couldn't quickly verify on Google).

~~~
keepper
Of course they provide source! Source rpms and tgz are downloadable.

Enterprise isn’t gpl, but source is provided.

(This could have been easily answered with a google search, as you pointed
out)

~~~
SilasX
No, I meant that I did search it on Google, and couldn't easily see from the
results which case it is. Google "mongodb enterprise source code" \-- which
one answers the question?

If it were so easy, you could have provided the citation yourself in that
comment.

------
dstaley
If I'm reading the pricing page correctly, DocumentDB would run a _minimum_ of
$200/month. That's for the smallest instance and no storage or I/O. Kind of
steep if you ask me.

~~~
rafaelturk
Besides that AWS will charge per transaction (at 0.2 per million) outrageous
given that you already pay per instance.

Correct pricing strategy needs to be per request or per instance, AWS is
charging for both

~~~
mabbo
The correct pricing strategy of any product is "whatever the customer is
willing to pay for it". If you feel the price is too steep for your use-case,
then don't buy it.

~~~
LamaOfRuin
That's rarely actually true for anyone that wants to operate for more than a
short time period. There are significant costs to gouging your customers.
Anything from it being illegal, to it encouraging competition and your
customers being motivated to actively flee you and shit on your reputation.
The correct pricing strategy for people that don't have a long term
enforceable monopoly is "whatever most customers are willing to reasonably
happily pay"

~~~
kllvql
I think you've hit on what always bothers me about this sentiment. It is
obvious that at any point in time you can charge the maximum customers are
willing to pay, but that allows for disruption through the channels like
competition. The opposite where you charge the minimum to continue providing
the goods or services seems optimal, though, leads to a company with zero
profits that is unattractive to investment. Is there any literature on how to
identify the optimal point of "whatever customers are willing to reasonably
happily pay"? Businesses successfully exist on many points in the spectrum of
zero profits to most profits the market will bear, but I'd be interested in
anything discussing optimality.

[Edit] Amazon employee working in Physical Consumer (not AWS). Asking out of
personal curiosity.

~~~
LamaOfRuin
I'm not an economist, and can't point to to anything in particular, but I
would be skeptical of anything that claimed a general approach to that.
"Optimal" depends entirely on what you're optimizing for, which is basically
an infinite possibility space. I could need a significant amount of revenue
immediately to accomplish a desired business development, or I could have
plenty of cash and want to build a large and loyal long term customer base at
the cost of immediate profit. As you say, successful businesses exist doing
pretty much everything. The only limiting factor is being a viable ongoing
concern (and that can just mean having a rich backer). I'm sure there are
things discussing optimizing based on small slices of the possibility space
though (but all the normal caveats about economists making dumb assumptions
that rarely apply to humans apply even to those).

------
vaer-k
Finally an AWS service where the name makes sense and describes what it is. I
hope this is the start of a trend.

~~~
rjbwork
I love Azure for this. The names are almost all extremely straightforward.
There are a handful that have made the jump from confusing to straight
forward, and a handful that have made the jump from straightforward to
confusing (CosmosDB, formerly DocumentDB, chiefly comes to mind).

~~~
Someone1234
Agreed. Too bad the Azure portal is the polar opposite. AWS, for all its
faults, is mostly just a boring HTML portal but it works.

Azure tried to get fancy, with side sliding panels all over the place, and it
is barely useable. The nicest thing I can say is it is "quirky." It isn't
really productive however, particularly not on my 1080p monitor at Windows
10's default 125% DPI.

I literally quit Azure's Application Insights and went back to Google
Analytics simply because I hated the Azure UI with a burning passion of a
thousand suns.

The concept of writing queries is good, but if that's the only way you can get
at your data you better make it damn easy, and they didn't. I'm sure for full
time data pros it is a dream however.

~~~
dharmab
Azure Portal feels like if someone tried to make the Xbox 360 blade interface
into an admin tool, without first asking the admins what they needed.

------
bnjmn
Looking through the supported APIs
([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-
apis.html)), it appears DocumentDB has no support for Mongo's oplog
([https://docs.mongodb.com/manual/core/replica-set-
oplog/](https://docs.mongodb.com/manual/core/replica-set-oplog/)), or change
streams
([https://docs.mongodb.com/manual/changeStreams](https://docs.mongodb.com/manual/changeStreams)),
which I guess is no surprise because change streams were introduced in Mongo
4, whereas DocumentDB copied the 3.6 API. So DocumentDB seems much less useful
as a reactive data store than MongoDB.

In other words, DocumentDB is only a drop-in replacement for MongoDB if you
weren't using any of the features Amazon decided not to support.

Happy to be corrected if I'm misreading the documentation!

~~~
InspiredIdiot
Also the aggregation pipeline is seriously hobbled with way more No-s than
Yes-es over here
[https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-
apis-aggregation-pipeline.html)

------
0xFFFF0000
Weird question: Could Microsoft sue Amazon here for infringing on the
DocumentDB name? I mean Microsoft's DocumentDB was among the first to even
have such a MongoDB layer also) and that was like 3 years ago.

Given that current Amazon leaders actually came from Microsoft's data platform
group this leaves a bit of a bad taste behind.

I'm not working for either company.

~~~
jon-wood
My assumption is that DocumentDB falls into a category of being so generic you
can't trademark it, or otherwise claim exclusivity to it. Its literally just
describing the fact this is a database for documents.

~~~
SmellyGeekBoy
Bear in mind we're talking about the company that trademarked "Word" and
"Excel" here.

------
misframer
Sounds like this runs on the same storage service as Aurora.

~~~
misframer
Not sure why I'm getting downvoted. The characteristics sound exactly like
Aurora.

\- "replicates six copies of your data across three AWS Availability Zones
(AZs)" [0]

\- "Amazon DocumentDB uses a distributed, fault-tolerant, self-healing storage
system that auto-scales up to 64 TB per database cluster." [0]

\- "When writing to storage, Amazon DocumentDB only persists a write-ahead
logs, and does not need to write full buffer page syncs." [1]

[0] [https://aws.amazon.com/documentdb/](https://aws.amazon.com/documentdb/)

[1]
[https://aws.amazon.com/documentdb/faqs/](https://aws.amazon.com/documentdb/faqs/)

~~~
MrTonyD
Yeah, downvoting is totally broken on Hacker News. Seems like anything that
isn't immediately agreed-with gets downvoted. I don't know where all the
small-minded people come from, but they seem to have found their home here.

~~~
ma2rten
There is just some random noise. It might just have gotten one downvote. Now
it's the top-comment.

------
XorNot
I'm pretty sure this is going to kill Mongo as a company dead. With this in
existence there's literally no reason to use Atlas.

If they wanted to twist the knife they should get to work implementing a pass
through migration option.

~~~
alittletooraph
Have you heard of Amazon Elasticsearch Service, launched in 2015? Elastic is
doing fine.

~~~
scarface74
Elastic Co isn’t profitable by definition it isn’t “doing fine”.

From their SEC filing:

[https://www.sec.gov/Archives/edgar/data/1707753/000119312518...](https://www.sec.gov/Archives/edgar/data/1707753/000119312518266861/d588632ds1.htm)

 _We have a history of losses and may not be able to achieve profitability or
positive cash flows on a consistent basis. If we cannot achieve profitability
or positive cash flows, our business, financial condition, and results of
operations may suffer._

~~~
alittletooraph
You're right they're not profitable — and neither is MongoDB — but the point
is that AWS launched an Elasticsearch service 3 years prior to Elastic having
a very successful IPO supported by stellar metrics (also found in the SEC
filing you linked). So the statements made at the beginning of this thread are
probably a bit premature.

~~~
scarface74
Only in tech do people think that a money losing company is “successful”
because they were able to convince investors to buy stock instead of defining
success as having a business model where income is greater than expenses.

In reality long term profitability is the only metric that matters for a
corporation

~~~
privateSFacct
And in contrast to these startups with their "success" AWS is printing cash
for amazon which releases surprisingly few "metrics" beyond $ in and $ out.

~~~
scarface74
And at the end of the day. What else matters when measuring whether a profit
seeking corporation is successful?

------
codepopacy
Dj from MongoDB here. We have, obviously, been keeping up with this and other
threads, but we've also been busy testing out Amazon DocumentDB's correctness
and performance. While we're getting that together to bring you an official
response in a few days, complete with test results and methodology, I'd like
to pick up on a couple of points and some inaccuracies that have been repeated
in various threads:

This move shows MongoDB’s approach to document databases is compelling. We’ve
thought so for a long time.

A cloud-hosted, truly global and managed MongoDB, MongoDB Atlas, has existed
for the last two and a half years and has been serving more and more satisfied
users every day with some massive workloads.

MongoDB Atlas runs the full implementation of MongoDB in the cloud.

Many features of MongoDB are documented as not being implemented by
DocumentDB: these include change streams, many aggregation operators including
$lookup and $graphlookup. But beyond that, well let’s just say we’ve been
staggered by how many tests DocumentDB has failed (no spoilers!).

The MongoDB API is not under an Apache license.

MongoDB drivers are still under the Apache license. The MongoDB server used to
be licensed under AGPL and is now licensed under SSPL. The source code is open
to all, as it has always been, at
[https://github.com/mongodb/mongo](https://github.com/mongodb/mongo)

DocumentDB is not cheaper than MongoDB Atlas. Preliminary estimates show this
to only be the case with very large collections and very, very high read/write
workloads.

There’ll be more next week over on the MongoDB blogs.

Dj

~~~
therealdrag0
Any idea when Atlas will expand support for Sharding configurations and
taggable zones? My impression is Atlas ONLY supports a 2 field shard, and the
first shard MUST be location. Also it's impossible for clients to set write-
concern to tags, because you don't support custom tags as MongoDB itself does.

------
keepper
The current biggest threat to Free and Open Source software is cloud
computing. Plain and simple.[0]

I know this is a blunt and harsh statement to make, but when you sell a
service, you have zero native incentives to Open Source the way your system
works. It just opens up Competition. This is not unique to AWS/Amazon. But
their success gives them the power to have wide OSS damage.

This is, to me, the biggest reason why cloud portability should be something
that every customer of a cloud service should have in their plans. Amazon as a
company has shown no timidness in both "embracing, extending, extinguishing"
their competition.

OSS literally built the internet and opened up the wold wild communication
age, let's not be so short sighted that we don't see proliferation of cloud
services ( specifically one having so much dominance), for what it really is.

[0] [http://dtrace.org/blogs/bmc/2018/12/14/open-source-
confronts...](http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-
its-midlife-crisis/)

~~~
SilasX
Cloud computing was arguably an outgrowth of inability to prevent piracy and
everyone being encouraged to open source everything.

~~~
keepper
No, it was an outgrowth of infrastructure work being a niche trade, and
capacity management by startups ( and mature companies), being a hard task.

This point is well known, and pretty much in every cloud providers marketing
material.

~~~
SilasX
So, even though it's impossible to prevent piracy, effectively forcing you to
hide the code behind an internet API, the real reason to do so is something
else, as proven by marketing literature?

If I could re-engineer MongoDB so that a monkey could administer, you'd
recommend I still use the cloud model rather than sell binaries?

------
luhn
Why is it so expensive? Not only is the entry point $200/m, the instances are
twice the price of their EC2 equivalents. (At first I thought perhaps the
price included multi-AZ, but it doesn't.)

------
jchw
Seems like this is likely to be the real result of licenses like the SSPL. Not
even a terrible outcome if the different implementations remain relatively
compatible.

~~~
wmf
SSPL style licenses only work if the software can't be cloned but that's a
difficult assumption.

~~~
earenndil
Operating systems, compilers, and web browsers come to mind. There are
currently:

* 4 independently-developed competitive compilers (gcc, clang, msvc, icc)

* 4 independently-developed competitive operating systems (windows, macos, linux, and bsd --I'm grouping the BSDs as one since their source code has a common ancestor)

* 3 independently-developed competitive browser engines, soon-to-be 2 (edgehtml, gecko, webkit)

And it's been that way for a few decades now; doesn't look like anyone is
interested in taking the resources to make another one of those.

~~~
johncolanduoni
Throwing Chrome/Blink under WebKit is a pretty hard sell at this point.
They’ve diverged enough that supporting one far from guarantees you’ll support
the other. You might as well replace WebKit with KHTML in your list.

~~~
earenndil
For the purposes of licensing and simple inertia (what it takes to start a
project from scratch) -- that work was done once, with khtml, sure.

------
manigandham
So now AWS DocumentDB, Azure CosmosDB, and even Apple's FoundationDB have a
MongoDB compatible API. I expect other multimodal databases to offer the same
soon enough.

Strange turn of events for MongoDB but I guess that's what happens when the
interface is open and anyone can build a backend to it, especially a
relatively simple document-store.

~~~
ec109685
And when they have a restrictive license.

------
social_quotient
I really wish this were priced more along the lines of
[https://www.compose.com/pricing](https://www.compose.com/pricing) \- a $200/m
floor is a tough dB cost to absorb on smaller yet important projects. Suppose
an app has a few mb of data and maybe one day hits 100mb of awesomeness I
really have to pay $200/m here?

I get it, I love Aws, just wish this was priced differently.

~~~
illumin8
If you need a cheap/free document store for a small app, just use DynamoDB.
It's free (forever, not just the first year) up to 25GB of storage and enough
read/write capacity units to handle up to 200M requests per month:
[https://aws.amazon.com/free/?awsf.Free%20Tier%20Types=catego...](https://aws.amazon.com/free/?awsf.Free%20Tier%20Types=categories%23alwaysfree)

~~~
privateSFacct
Exactly, this probably isn't targeting you. A few mb of data? Host an
instance? Use sqlite? Atlas can run 3-5k/month as the minimum. This is going
to be 10x cheaper (which amazon seems to try and shoot for).

------
notmyname
seems an obvious response to [https://www.mongodb.com/press/mongodb-issues-
new-server-side...](https://www.mongodb.com/press/mongodb-issues-new-server-
side-public-license-for-mongodb-community-server)

~~~
tootie
Azure has been running a Mongo-compliant DB under their Cosmos umbrella for
quite a while. It's not clear to me that either Azure or AWS are actually
running Mongo software under the hood or rather a proprietary DB that uses the
Mongo wire protocol.

[https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-
int...](https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction)

~~~
Analemma_
Doesn’t Azure also have a not-Mongo service also called DocumentDB? Is this
the same code? These cloud services are confusing enough when they don’t
borrow each other’s names.

~~~
nlawalker
The Azure service formerly known as DocumentDB is now called Cosmos DB. Part
of that switch was introducing multiple APIs, including a MongoDB API:
[https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-
int...](https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction)

------
morpheuskafka
I really wish this was serverless. Azure CosmosDB offers SQL and MariaDB
interface against a serverless, pay for what you use database and DynamoDB is
the only product of that class Amazon has. Even Aurora "serverless" appears to
be little more than autoscale, and it requires an elastic IP which slows
launch of lambdas since they have to connect to VPC.

~~~
iamed2
> it requires an elastic IP which slows launch of lambdas since they have to
> connect to VPC

Do you have any other info/links related to this?

~~~
gazzini
There's an enlightening graph in this post:

[https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-
lat...](https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-latency-
killer-5408323278dd)

I was surprised to learn this. When working in Lambda, you have to choose
between a relational database & a responsive API. It seems inevitable that AWS
will fix this soon, but apparently this is a significant architectural
problem. As I understand it, RDS instances should (must?) be accessed from
within a VPC, and anything inside of a VPC needs an IP address, so the Lambda
function has to wait ~10 seconds on cold-start for the Elastic IP service.

The only workaround I've heard of is to setup a service, such as CloudWatch,
to call your Lambda function every ~25 secs to keep it "warm", but this seems
anti-thetical to the value proposition of serverless architecture in the first
place.

Of course, you could "just" use DyanmoDB, but IMO the query language is really
limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need
to be accessed from within a VPC?)

~~~
athrun
> I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be
> accessed from within a VPC?)

This is due to the fact that DynamoDB's query API is a standard AWS API which
means granular internal/external access can be provided through IAM mechanisms
(ie: roles, temporary tokens, federation, etc.).

On the contrary, to access RDS, Redshift or DocumentDB you would use standard
ODBC/JDBC/Mongo facilities, which do not rely on IAM mechanisms, leaving
VPC/Security Groups as the only isolation option.

~~~
koolba
Not quite. It’s not the auth mechanism or even the wire protocol. The issue is
to accesS traditional resources in a VPC you need to have an IP address within
the VPV to route network traffic to/from it. It’d be the same if you ran a DB
on and EC2 instance or even ran your own DynamoDB clone with no auth.

AWS services don’t have that issue because they’re accessible from anywhere on
the network, even through an internet gateway / internal NAT.

~~~
athrun
I think that was my point.

Services with "native" AWS APIs use IAM for granular access management. Other
services can only support access restrictions using the network so that means
VPC/Security Groups.

------
markwolfe
This looks great for teams getting started in AWS, being able to reuse idioms,
libraries and knowledge in managed services to remove some of the operational
load.

A note this is also nothing new, Azure Cosmos DB has had this for a while.

------
whalesalad
Serious question: is there any real reason to use Mongo over Elasticsearch?

~~~
throwaway204
ES grew out of Lucene, which provided an inverted index of all the text in a
document, with a bunch of NLP related features bolted onto that. While
ostensibly designed to be developer friendly, ES had and still has a horribly
hacked together API with bugs and mis-documented misfeatures all over the
place. In my experience it's anything but developer friendly. But if all you
need is a text index on a document store with a static schema, it does its job
reasonably well.

Mongo started as a very developer-friendly data store with lots of overstated
claims to being a database. While earlier versions of Mongo were wildly
dangerous to use as a business critical database, it has since matured and is
now quite good at being a developer-friendly document-centric database. In my
experience Mongo truly is developer-friendly as long as you don't try to use
it as a full-blown transactional database with lots of complex data shapes and
indexes.

I would not trust ES with anything but text search on a document store, and I
would not trust Mongo with anything resembling multi-document transactions.
With that said, they are both good at specific, different things.

MySQL and Postgres have their own baggage that makes them pretty terrible in
some aspects. IMHO a JSON-over-HTTP API should really be table stakes for a
database to be considered developer-friendly nowadays. (But please don't
butcher HTTP like ES did and then claim to have that.)

~~~
zepolen
> IMHO a JSON-over-HTTP API

No no no no, again no.

We don't need yet another shitty query language bolted onto one of the most
error prone and annoying to type serialization formats while transmitting data
on top of a by default stateless protocol that makes no sense for a database.

I'm sick of it.

SQL. The same queries will work in 95% of the case on any SQL db. There is a
driver in almost every language that is robust. There are implementations
great for every use case; embedded, scalable, transactional. _That 's_
friendly.

There is nothing wrong with SQL, it's freaking awesome.

~~~
throwaway204
Sure, keep the SQL. Just make it a field in a JSON POST payload, and send the
results back as JSON.

The "drivers in almost every language" suck. They all suck. I've never seen a
SQL driver and wire protocol that was not awful in some way. The statefulness
is part of what makes them awful. We have better ways to keep track of state
now.

~~~
pritambaral
> I've never seen a SQL driver and wire protocol that was not awful in some
> way.

Have you seen the PostgreSQL wire protocol[1]? I recently built a logical
replication client driver for a project and found the protocol to be
excellent. After looking at the documentation, I'm no longer limited to
languages that have drivers for Pg, because I know how easy it'd be for me to
just write one.

Just because _some_ SQL drivers and wire protocols are awful (looking at you,
Oracle[2]) shouldn't mean one should go running to the hills, let alone to
JSON.

\----

1:
[https://www.postgresql.org/docs/current/protocol.html](https://www.postgresql.org/docs/current/protocol.html)

2: [https://noss.github.io/2009/04/28/reverse-engineering-
oracle...](https://noss.github.io/2009/04/28/reverse-engineering-oracle-
protocol.html)

~~~
int_19h
An HTTP/JSON protocol doesn't have to replace the standard one. But having
such a standard protocol makes sense in the age of web apps, particularly when
NoSQL offerings that are perceived by the market as competitors (leaving aside
whether they really are - perception matters more here) do that already.

~~~
pritambaral
> An HTTP/JSON protocol doesn't have to replace the standard one.

So, two protocols? Two _standard_ protocols is rarely better than one.

> having such a standard protocol makes sense in the age of web apps

Only if the existing standard protocol cannot work with the "web", and we have
plenty of history proving otherwise. _Replacing_ the existing standard with
the loose JSON would be, strictly, a downgrade; and unnecessary, because we
already do interoperate JSON and SQL. See: PostgREST and the many REST &
GraphQL frontends on PostgreSQL.

> particularly when NoSQL offerings that are perceived by the market as
> competitors (leaving aside whether they really are - perception matters more
> here) do that already

This is really more of going into a pig's pen and wrestling with them. A
database should do the job of a database. Competing for perception in a market
that cannot make sane decisions for itself is how we get MongoDB.

------
christkv
There is a serious amount of weasel words in that statement. Implementing the
Apache 2.0 API I think is just weasel words for "Works more or less with the
MongoDB drivers" which is the only thing Apache 2.0 licensed that I know off
and is obviously not the API which is the combination of the MongoDB
wireprotocol and the commands supported by the MongoDB server.

------
mark_l_watson
Looks good. I used to use both MongoDB and CouchDB (for very different use
cases) a lot but haven’t touched them in a long while.

~~~
anonytrary
Out of curiosity, what use cases did you have for CouchDB that weren't
feasible with MongoDB?

~~~
WorldMaker
In my case, at least, PouchDB is still a lot handier of an offline-first
mobile-capable DB than just about anything else, and because it speaks the
CouchDB replication/sync API that still leaves a lot of use cases where
CouchDB is more feasible. (It would be great to have more document DBs
converge on a replication/sync API for offline-first applications. I've voted
on the UserVoice suggestions to CosmosDB on the idea.)

~~~
karmelapple
Same here. We love how replication is built in to CouchDB from the ground up.

I wish MongoDB, which seems to still have more love for it in the world than
CouchDB/Cloudant, would have that replication built-in.

~~~
metheus
Wait... do you mean something other than
[https://docs.mongodb.com/manual/replication/](https://docs.mongodb.com/manual/replication/)
?

~~~
karmelapple
I'm thinking about the use case to have a native app be able to work nicely
with no internet connection, but then once the internet connection resumes, it
downloads new data from the server and sends its offline-modified data up to
the server.

From a quick search online [0] [1], I see people doing offline MongoDB sync
using SQLite, but nothing like using Mongo directly. With CouchDB, we can use
either the old Couchbase native app SDK, or the Cloudant native app SDK, to
sync up nicely with a CouchDB instance in the cloud. We've had this running
for awhile, and it works quite well, and we do not have to shuffle information
to and from a SQLite database... at least, we're not doing it, since the
Cloudant or Couchbase SDKs for iOS and Android keep track of all the data and
store it on the mobile device however they'd like.

If there is anything similar for Mongo, I'd be interested to know!

[0] [https://stackoverflow.com/questions/23623295/how-to-make-
an-...](https://stackoverflow.com/questions/23623295/how-to-make-an-android-
app-work-in-offline-mode-in-android) [1]
[https://stackoverflow.com/questions/13295960/sqlite-on-
andro...](https://stackoverflow.com/questions/13295960/sqlite-on-android-and-
mongodb-with-synchronization)

~~~
metheus
Dunno if this thread is too cold for you to notice my reply, but there
absolutely is... MongoDB Mobile was released last year, and along with Stitch,
MognoDB’s serverless application platform, you can get exactly what you want —
mobile sync.

------
koolba
Jeff Bezos continues his quest to eat all open lunch boxes.

~~~
0xFFFF0000
Microsoft was first with a MongoDB layer, like some 3 years ago I think.
Nothing novel here from Amazon.

------
borplk
While we are on the topic, are there cloud providers out there that provide
"hosted FoundationDB as a service"?

And if you are curious, no I don't have any special need or use case for it,
just wondering.

------
anonytrary
AWS lacked something like this before, which is why I used MongoDB Atlas
(MongoDB's own managed mongo service). How is this different than DynamoDB
(other than the obvious API differences)?

~~~
dfischer
DynamoDB has specific requirements on how data is partitioned. You have to do
upfront planning on how you access your data based on keys.

Mongodb is more flexible in this regard.

I’m sure there’s other big differences but this is the biggest to my
experience with both.

~~~
anonytrary
I was asking about DocumentDB, not MongoDB, but maybe I missed something. From
their site:

> Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API by
> emulating the responses that a MongoDB client expects from a MongoDB server,
> allowing you to use your existing MongoDB drivers and tools with Amazon
> DocumentDB

So, is this a "managed MongoDB" or is it a NOSQL AmazonDB that just implements
the same API as MongoDB? If the latter, I don't think we can assume this is
the same thing as MongoDB, because the internals might be completely
different.

~~~
k__
Sounds like the latter to me, they probably implemented it on top of one of
their other DBs.

~~~
anonytrary
Lmao I was a bit afraid this might be some surface-level API wrapper around
DynamoDB, in which case this is less cool than I thought. It doesn't seem to
be the case at a first glance but I wish it was a bit more clear on the site
exactly how this relates to DynamoDB, if at all.

Maybe I'll just have to read more about it. Hopefully the internal
architecture gets away from DynamoDB-style partitioning.

~~~
jon-wood
From other comments here it looks like its built on top of Aurora rather than
DynamoDB.

~~~
k__
On the other hand they used MySQL as DynamoDB base, so maybe they will switch
DynamoDB to Aurora too?

------
talawahdotnet
I am pretty frustrated that DB services like Aurora, and now DocumentDB are
still limited to last-gen instance types like r4 instead of the latest
instances like r5 and t3 which have marked improvements in terms of CPU and
networking performance.

I wonder if it is that they just have a so much r4 inventory left that they
are forcing us to use it or if they haven't fully integrated/validated the
latest instance types with their custom storage backend.

------
sauravt
How is it better than buying a MongoDb subscription from the AWS marketplace?
[https://aws.amazon.com/marketplace/search/results?x=0&y=0&se...](https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=mongodb)

------
0xfffff
Wasn't DocumentDB the old name of Azure Cosmos DB? just marketing wise this
seems like a bad choice for a name.

------
vemv
I hope AWS realises that harming OSS authors, even indirectly, is
counterproductive to AWS' interests.

If Mongo dies, so does its userbase, and so does DocumentDB.

How to fix it classily? Contribute back with code maintenance or whatever
customizations were developed in-house.

Also you get to save face - you are not perceived as a leech anymore.

------
StreamBright
I hope MongoDB's users are really keen on on-prem otherwise this might be a
challenging moment for them.

~~~
threeseed
Not sure what this means.

MongoDB has had Atlas which is a cloud hosted solution for a while now.

~~~
ec109685
Poster means that their cloud business could be impacted, but on-prem (non
aws) would not be.

------
orestes910
Is it really THAT hard to to run on prem/cloud because of the "complexity that
comes with setting up and managing MongoDB clusters at scale"?

The documentation is strong, it was built with horizontal scalability in mind.
I don't see the struggle.

~~~
uberduper
Yes. Sharded mongo has many pitfalls that can challenge your devs, dbas and
devops people. Mongo api without all the mongo scaling problems is pretty
awesome.

~~~
chx
I must have used a different API, then. Well, obviously not but it could
happen because there are more than one ...

I agree with [https://www.linkedin.com/pulse/mongodb-frankenstein-
monster-...](https://www.linkedin.com/pulse/mongodb-frankenstein-monster-
nosql-databases-john-de-goes/) the contents of this article (and reserve
critique for its author). Even the basic query language, in particular
$elemMatch is atrocious which has a certain irony to it because Eliot added it
when we asked for the functionality
([https://jira.mongodb.org/browse/SERVER-377](https://jira.mongodb.org/browse/SERVER-377)),
so long ago. We have been one of their first commercial support clients, my
boss needed to pressure them to accept money for support, they didn't want
to...

------
craig_peacock
I would actually like to thank AWS for focusing on supporting Open APIs. Let
the community design the standards and operations and let the vendors compete
to implement them, open source included.

------
hendry
Atlas is $0.03 per server hour, Amazon starts at $0.277

Do I have that right?

~~~
manigandham
Starting prices maybe, but you have to compare hardware and performance
capacity, not just flat numbers.

------
jonplackett
Shame there isn’t a free tier equivalent. I’d like to try some projects using
mongo but $200 a month minimum does not work for Indy projects.

~~~
metheus
Try the free tier on Atlas.

------
KaoruAoiShiho
Can someone do a comparison on pricing vs Atlas and vs DynamoDB and Amazon's
managed postgresql?

------
LoSboccacc
> Text Index: No

as MS Cosmo DB prior, the compatibility list leaves quite a bit out.

------
miaklesp
Of all possible names they managed to choose already obsolete name for a
similar product from Azure?

Azure in 2017: forget DocumentDB, Cosmos DB is the new thing now!

AWS in 2019: We just released DocumentDB!

Are they so geniuses or so idiots?

~~~
0xFFFF0000
I had the same observation (although I'd reconsider your wording, that's not
very polite). It doesn't seem like a good choice in naming - especially
because many of the Data Platform folks at Amazon (like their VP) came from
Microsoft's data platform group.

------
hguhghuff
Is this serverless?

Pricing?

------
swoorup
I cant use this crap locally?

------
outworlder
How the heck was this approved by legal? AWS is linking to MongoDB's own
documentation.

[https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-
apis.html)

Go to any operation, it links to docs.mongodb.com !

~~~
chrisseaton
Is linking to documentation illegal?

~~~
outworlder
The 'legal' department doesn't only vet things that are obviously illegal,
they are there for other things too, like EULAs, contracts and intellectual
property in general.

In any case, they are implementing the competitor's APIs and the documentation
is already licensed as Creative Commons. Can't they at least host their own
copy?

