Hacker News new | comments | show | ask | jobs | submit login

I don't know what kind of project it is - but have you actually considered just using Postgres? Its not hip and takes a bit to setup, but after you are done, you have reliable workhorse with all the stuff you need (access control, schemas, etc. pp.) It has a vast amount of documentation and reading about its advanced features never gets old. There is a lot of talent around that knows how to use it. If you still consider Ruby but don't like ActiveRecord magic, don't forget to have a look at Sequel.

I would recommend against DataMapper. It is nicely constructed, but has some weird issues. Also, DataMapper 1 is going to be replaced by DM 2, which is a completely different beast (but better, hopefully).

Don't be fooled by ease of setup of the DB too much. It should be rather straight-forward, but even if a DB can just be downloaded and ran to dabble with it, always remember that this just shifts the moment at which you really have to dig into the details. You don't want to do that 2 days before going to production. Be on the lookout for red flags, though: unreasonable and weird configurations that have to be flipped for no understandable reasons at all before going into production. That shows that the project is not maintained very well or the developers have lost track. Also try to figure out how long it takes you to solve a new problem with the database, with documentation reading and all. Pick the one that you can wrap your head around best.

I have a FreeBSD box in my closet (I felt like playing with FreeBSD this weekend) currently running Postgres 9 and PostGIS which is how my current stuff is working.

It's actually pretty rad to have every single location I've ever checked-into via Facebook stored in this database. I can say "find all the spots 2 miles from my house" and it's shockingly quick.

I have PostgreSQL on my mac. It's easy to install and use.

PostGIS was the killer. Version 2.0 (homebrew installs postgis2) does not play nice with Django locally (on my mac) and the ticket has been open for a year or something to fix it. That's a huge red flag for me right there. https://code.djangoproject.com/ticket/16455

I guess I could install 1.5 manually.

My problem with trusting Ruby/Rails is that I've only been seriously developing in it for a month.

Okay, but thats more a Django problem then a PostGIS problem.

Lets put it like that: feel free to try some new stuff, but don't start getting all crazy with it. So, if you tried Rails and weren't that convinced by it, maybe default to something that you know, even if it isn't a love relationship. Learning is a great thing, but do it piece by piece, especially if your goal is getting work done.

How quick exactly?

I've been testing ElasticSearch's geo location search and most queries take 50-150ms.

Standard term searches and filters will take like 5ms, with id GETs taking mere fractions of that still.

Well, compared to your numbers, I guess not that quick. Django is responding in 0.28 seconds. That is going over wifi to my server in a closet though. And i'm downstairs kinda far from the router.

Screenshot: http://wsld.me/J5zu

If I hit it repeatedly for a while it comes back in as quick as 0.14, but usually not that fast.

ping to server:

    michael at Achilles in ~
    ○ ping -c 5 apollo 
    PING apollo ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=64 time=9.497 ms
    64 bytes from icmp_seq=1 ttl=64 time=83.113 ms
    64 bytes from icmp_seq=2 ttl=64 time=7.335 ms
    64 bytes from icmp_seq=3 ttl=64 time=6.998 ms
    64 bytes from icmp_seq=4 ttl=64 time=6.393 ms

    --- apollo ping statistics ---
    5 packets transmitted, 5 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 6.393/22.667/83.113/30.241 ms

I'd call it good enough, I was of the understanding that SQL database geo plugins were usually miserable. I'll add a mental exception for Postgres.

I used PostGIS in proper GIS scenarios and it was faring quite well. The advantage of PostGIS is that it supports all the index types you need directly. And been around awhile, in a good sense.

Setting up Sequel and Postgres is really easy. sudo apt-get install postgresql, gem install sequel... and I think that's about it.

I didn't say its hard. But setting up all users properly etc. (which you definitely should get comfortable with _before_ you have your whole dev environment running under 'postgres') takes a few minutes. It is a pretty unsurprising process though, which is why I wrote about the red flags: it doesn't raise any.

You must be joking if you think that count as 'setting up' a database also I just set up 4 servers:

apt-get install mysql-server redis riak-server mongo-10gen-server

Easy of setup matters. Because unless you are using a hosted database then you will be managing and maintaing that database day to day. Which is why I would never recommend PostgreSQL for startups. It is far, far too convoluted for many of the basic tasks you will be doing everyday.

That's why everyone chooses MySQL as a relational database. It is easy to setup, easy to maintain and EVERY problem has been solved and searchable online.

Wait... what?! I don't see any major differences between MySQL and PostgreSQL in terms of setup/maintenance. They have slightly different authorization styles, but Postgres can be configured to behave just like mysql.

Ignoring for a moment that postgres was my example, but not my point: choose what you can wrap you head around. I used postgres successfully in multiple projects an no one ever had a big problem with it. I've seen MySQL setups burning sky-high because of some Gotchas the team ran into. That doesn't make either of those bad.

The underlying issue is that (except for the most trivial cases), investing time in properly operating and using your database is a huge gain that many young companies ignore. 6 Month later, they have a burning datastore at hand that they don't know how to fix.

Exactly ALL databases will have issues. Which is why I suggested MySQL. Every issue has either been solved online or worked around in Percona, Facebook or Twitter's implementation.

There are huge benefits that come from being the most widely deployed database.

There's no good reason to use MySQL over PostGres these days.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact