
Show HN: Database Labs – Postgres as a Service - pjlegato
https://www.databaselabs.io/pricing/
======
liotier
> Yes, all databases are operationally managed by us. You never have to worry
> about maintaining the database or operating system.

I am not sure whether not having control over upgrades is a feature or a bug.

> We set up and maintain an optimized Postgres instance

Optimized for what ? Any non-trivial database is going to require tuning, for
which there is no one best way - only custom choices.

~~~
pjlegato
Hi, Database Labs founder here.

> I am not sure whether not having control over upgrades is a feature or a
> bug.

I think different people will have different answers to that question
depending on their circumstances and abilities. Some want full operational
control over everything, and others would much rather just have a database to
use that's always upgraded, monitored, backed up, and so on. Our target market
is the latter group.

Bear in mind that doing your own sysadmin work for your database is not free.
Besides the direct costs of paying someone to do the upgrades, test the
backups, and so on, it diverts human time and attention away from other
endeavors. Human time is a tech company's greatest asset, and we are betting
that a significant number of people are prepared to pay someone to handle all
of that for them, so they can focus on their core business.

> Optimized for what ? Any non-trivial database is going to require tuning,
> for which there is no one best way - only custom choices.

Yes, you are absolutely right. Out of the box, our databases are tuned for
what we perceive to be a "generic average web app workload" on the underlying
host type that they use. I realize this is rather vague and does not cover
many use cases.

Use case specific tuning is definitely on the feature list for future
versions. Do you have any insight on how that could be implemented in such a
way that it'd be a good value for you? In other words, can the broad array of
custom choices be reduced to any smaller set of useful patterns?

~~~
liotier

        >> I am not sure whether not having control over
        >> upgrades is a feature or a bug.
        >
        > I think different people will have different answers
        > to that question [..]
    

Yes, as long as the features remain reliable. But sometimes, though rarely, an
upgrades retires an API or worse, changes a default behavior. I guess that you
have thought about that, but that is what I meant with my original question...
Sometimes you have to choose between feature stability and newer versions (for
new features or, more importantly, bugfixes). How will you handle that balance
? What guarantees does the customer gets either way ? Doesn't making it
explicit to the customer comes in conflict with hiding the gritty details of
database server operations ?

~~~
pjlegato
Our guarantee to the customer with regard to the upgrade process is that we
will use our best efforts and accumulated knowledge to make the right
decisions about how to manage the thorny questions around the upgrade process,
to which there are no universally correct solutions, so that they don't have
to do so.

Of course, it's very easy to say some nice-sounding words like that. The real
evidence can only be demonstrated over time, after many successive trials,
through building up an ongoing relationship of trust with our customers and
repeatedly demonstrating that we make the right calls most of the time.

With regards to breaking Postgres changes specifically, they are rare and
almost always announced well in advance, giving us ample time to message the
users, prepare them, and manage the transition.

I see this stage of the database market as analogous to e-mail in the early
2000s. At the time, most people read e-mail delivered by a custom Sendmail,
Postfix, or Outlook installation. Many felt that the numerous gritty details
of running an e-mail server meant that every site needed its own mail daemon,
customized to its particular needs.

There were a few email-as-a-service offerings like Hotmail, but many admins
felt they were too limited for serious business use cases.

It turns out that most businesses actually just needed GMail -- a really well
done email-as-a-service platform. Sure, there are still some places that
really do need a custom e-mail setup, and they continue to use custom
software. For 80% of all businesses, though, a Google Apps GMail account is
more than adequate. They trust that GMail's admins will make the right call.
We aim to do the same for databases.

~~~
liotier
I still run my own mail server... But I understand your point - the reasons I
still do are mostly not technical.

------
bdcravens
I'd like to see distinctive feature list (and not the underlying cloud
provider's features). How is this better than spinning up a pg instance on AWS
RDS? Heroku Postgresql? Or if you're running a Rails app, pointing Cloud 66 at
your repo and your Digital Ocean account, and getting a full stack built?

~~~
mrweasel
A feature list would be nice. One reason you might want to avoid Amazon could
be that you're competing with Amazons other business, so using their AWS would
be a bit weird, not that I think Amazon really care.

Option and competition is good, and being able to buy into a well managed
hosted Postgresql is really appealing if you don't have the resources to
manage a database installation yourself. Currently the alternatives for
Postgresql is really expensive. EnterpriseDB have a nice offering, but it's
really expensive.

All this of cause assumes that databaselabs.io isn't just two guys with a
server in their basement.

~~~
exhilaration
_All this of cause assumes that databaselabs.io isn 't just two guys with a
server in their basement_

Or two guys with an AWS account!

------
VLM
What does this mean:

"All databases are fully managed and tuned by us"

So... reactively you get tired of seeing disk io so you make indexes for me,
and/or I'm not allowed to define my own indexes, or are you talking more
server level like shared_buffers and work_mem? Or a third level like hardware
level where I'm using more CPU so you give some to me and take it away from an
instance not using it so much?

Just saying I'd see a difference in language like "schema level" vs "server
level" vs hardware level.

I'm indecisive about this. As a gamble, should I use you guys and pay a little
more for someone else to worry about differing levels of management and
tuning, vs spin up my own and worry about it myself...

~~~
pjlegato
Hi, Database Labs founder here. That phrase could be a little clearer, I
agree. I'm going to update the site soon to incorporate the feedback I've
gotten.

What we mean is that the Postgres system itself is "server / OS level"
management. We set up a reasonable set of defaults for a generic workload per
server type, and you get superuser access to the Postgres server to do what
you like with in terms of internal structure (schema, indices, users/roles,
and so on.)

We handle backups, OS upgrades, Postgres upgrades, monitoring, OS-level
security, firewalling, intrusion detection, and other sysadmin-like stuff. We
are on call 24 hours a day to deal with the issues that will inevitably arise,
and we proactively work to minimize the frequency with which they happen.

The value proposition lies in how you want to spend your time. Our feedback so
far indicates that a significant number of people would rather pay someone to
handle all of the sysadmin chores and focus their time on their core app.

Thanks for the feedback. I'll be updating the page soon to try to make the
value proposition clearer.

------
pjungwir
I don't see anything here about replication or even backups. To me that is why
I'd use hosted Postgres. RDS gives me multi-AZ failover but no access to the
slave for scaling read-only queries, no way to configure pushing WAL archives,
etc. (They do offer slave access for MySQL, so hopefully this is just a matter
of time.)

Going up against RDS, Heroku Postgres, and the dozens of existing hosted
Postgres vendors is a tough market. You have to offer more than just `apt-get
install` and some tweaks to postgresql.conf!

~~~
glutamate
> Fully backed up continuously, offsite, via WAL logging

~~~
yangyang
Replication and backup solve different problems. What if I accidentally drop a
table and need last night's backup? Are they archiving the WALs too so you can
do point-in-time recovery?

~~~
pjlegato
Hi, Database Labs founder here.

We do nightly snapshots plus ongoing continuous WAL logging, so yes, you can
do point-in-time recovery to any moment in the retention window. The retention
window is 14 days minimum, with longer windows available upon request.

~~~
yangyang
That sounds sensible, thanks; I'd misunderstood and thought you were doing
continuous replication to another PG server, now I realise you're archiving
WAL to S3.

------
runako
Congrats on your launch!

I'll offer some questions I'd be asking if I were on your board of directors.
I hope they are helpful as you grow.

\- It looks like your model assumes a base 50% materials cost. (I'm assuming
you're storing WALs in customer's S3 accounts, not yours.) After adding staff
and other costs, how likely is this to reach break-even?

\- And at what scale?

\- How do you differentiate if/when Digital Ocean starts moving up the stack
(assuming they will eventually want to move into higher-margin products a la
AWS)?

------
sanderjd
This looks nice! As others have mentioned, more details on what exactly "fully
managed" and "optimized" entails. I don't think the pricing is quite worth it
just for removing the server provisioning aspect (because others do that for
cheaper), but if you can automagically make my queries run faster without me
needing to think about it, then you're onto something. If that's the selling
point, I'd love to be able to find more details about it!

------
DonHopkins
I have a question for database wizards!

I'm developing an application that uses lots of little blobs of JSON to
represent objects. (Who isn't?)

I'm going to put them into a database, probably Postgres, maybe also Mongo or
something like that.

I'd like to keep the important JSON objects checked into git, either with the
source code they belong to, or as a separate repo. It needs to export and
import them all one to a file, as normalized pretty printed JSON, so git can
track and merge changes line by line, and recreate the entire system including
source code and matching data at a later point in time. Not everything in the
database needs to be tracked in git, just the important bits of JSON that need
to be kept in sync with the code.

What I want to avoid is having a huge monolithic database backed up in a
different way and on a different schedule as the source code is being tracked,
so the important JSON data is mixed up with bulky transient tables in SQL
dumps, so it's slow and tedious to recreate the source code with the matching
data. What I want is for it to be easy to track and merge and revert changes
to that important JSON data, and to back up the data in lock step with the
source code that depends on it.

Somebody must have tried something like this before -- is it a crazy idea, or
is there a better approach, or some system that tackles this problem already?
Thanks in advance!

~~~
rpedela
How much data are we talking about? If it is small and static, then it can
probably just be stored in git. If it is dynamic and/or large, the typical
solution is to have a separate table with diffs and timestamps. You could even
add the git checksum since you want it synced with git.

I would love to be more helpful. If you want to talk further about your
particular problem and possible solutions, please contact me: rpedela at
datalanche.com

------
dvcc
Taking a look at it, I would do something similar to what compose.io does with
its pricing model
([https://www.compose.io/pricing/](https://www.compose.io/pricing/)). Giving
out a free tier, gives the best introduction to something like a database as a
service.

It was what brought me over to a paid plan at compose.

------
ceejayoz
If your ticket priorities are "highest" or "high", "high" is just "normal".

------
egmracer
What kind of reliability/fault tolerance guarantees do you offer? Do you
implement multi-master clusters for postgres and offer a simple interface? Or
do you just install Postgres on a machine for someone?

~~~
pjlegato
Hi, Database Labs founder here.

We offer 99.99% uptime, with refunds for outages beyond that.

We can set up read replicas manually for you at this stage; a user interface
control for that is in the works. Multi-master is not available yet. If many
people want that, we'll add it.

What we do is a bit more than "just" installing Postgres on a machine. We
manage it for you as a system. By that I mean we do the sorts of boring
operational sysadmin tasks that are often overlooked and not accounted for
when one considers running a server: we do uptime monitoring, backups,
firewalls, operating system and Postgres patches, security / intrusion
detection, and so on; and we have staff on call 24 hours a day to handle the
inevitable problems.

All that stuff costs time and money, and we've found that many people prefer
to pay someone to handle it all so they can focus their time on building out
their core business rather than on learning to be sysadmins.

------
abstrct
How much configuration changes do we have access to behind the scenes? Any
chance the pg_hba.conf is available to the owner? Similarly, do we have access
to create additional roles/users?

~~~
pjlegato
Hi, Database Labs founder here.

You get superuser access to the Postgres server, so administratively you can
do anything at all that can be done from an interactive psql session -
create/delete/update databases, roles/users, privileges, and so on.

We don't currently have any way for end users to tweak pg_hba.conf or other
backend config files. We open up port 5432 for SSL-encrypted connections from
psql or any other Postgres-compatible software. Does that cover the cases
where you'd want to modify pg_hba.conf?

~~~
abstrct
Nice to hear about superuser. That's great.

Unfortunately it doesn't sound like it will cover my use-case, but admittedly
my scenario is a weird one (see
[http://schemaverse.com](http://schemaverse.com)).

Either way, thanks for the response and best of luck with the service!

~~~
pjlegato
Er. Wow, that's a pretty awesome idea!

You can create and update user roles without altering pg_hba.conf, which I
think would let you run most of that. What's the case where you'd need to
alter pg_hba.conf directly?

~~~
abstrct
Thanks! Come try it out sometime :D You clearly have an equal love for
postgres.

I asked because we have been considering ways for people to easily deploy
their own instance of the game (likely for educational purposes). So I try to
keep an eye open for new db services.

The technical reason for the requirement is that players connect from all over
but the system also needs to be able to connect as each player - preferably
without knowing their password. We normally handle this with a trust
relationship between specific servers. Alternatively we could be using a
superuser account and SET ROLE but that would require some other changes as
well.

------
hardwaresofton
The smallest thing is $10/month, that's way too expensive.

I think you might get more traction if you did more to explain exactly what
someone would be getting that price BEFORE you showed them the price.

Right now, the feature area (below the pricing), is so sparse and all over the
place that it's a chore to read.

It seems like you're going to completely manage the database side? if so, then
maybe you should say something like "we'll be your database guys". If it's not
that, and it's just hosting the database/making sure it's up then have some
sort of message specific to that?

~~~
mrweasel
I think $10/month is pretty cheap, assuming the service is good.

We're so use to getting a "free tier" or paying for some obscure gigabyte-hour
/ dingo-dyno tier. I like that these guys are upfront with that you need to
pay, and having easy to understand prices.

~~~
pjlegato
Hi, Database Labs founder here. We indeed are very upfront and transparent --
no hidden costs, and no teaser free tier followed by a massive price jackup
once you actually get any significant traction.

Free tiers also invite abuse by shady actors (spammers and so on) and tire-
kickers who generate support load but don't ever actually buy anything, which
we just don't have the resources to deal with yet, as a small company.

It seems so far that $10 is a reasonably low price point for trying it out
that people are willing to give it a shot, and it filters out a lot of the bad
actors.. maybe when we're larger, we'll revisit the free tier idea.

~~~
hardwaresofton
Yeah so I didn't mean that you should sell it for free, but the issue here is
that I an easily rent a VPS (and I do) with better specs for cheaper and it's
not super clear exactly what you're offering on top outside of "VPSes to run
database x" on.

------
__xtrimsky
So basically you are clearly specifying you are using DigitalOcean to host it,
and just multiply the price by 2 :/.

I don't know if that would attract someone, it doesn't work for me. Not enough
features for twice the price. I would advice only a small increase (+10% or
so).

Quick general question:

I have a server in Montreal. My server hosting doesn't have SSDs for cheap.
For a semi-big database (2gb), is it better for me to get a DigitalOcean with
SSD in New York? Would that improve my database, or will the ping slow it down
too much. (in my example the ping would be of about 23ms)

~~~
icot
If the whole database is 2GB, can you get a server big enough to have all your
data in memory, or at least the hot part of your data? That would be better.

~~~
__xtrimsky
It looks like a safe method is to make the innodb_buffer_pool_size a lot
bigger, and it will in fact store all the db in memory.

(Otherwise you need to set up a backup or a replication in case the server
goes down)

I'll play around with it, thanks!

------
rayanm
Wouldn't be better to host a web application and the database on the same
server for better performance?

~~~
rayanm
I'll answer my question. They tackle this problem by advertising as such:
"Lives in DigitalOcean, near your app" So basically, for optimal performance,
my app should be hosted on DigitalOcean.

------
SteventM8
does it have the ability to restrict access from specific IP's ?

