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

For years Microsoft-sponsored SQL Server consultancies have been telling us to use the database to its fullest extent. Use Stored Procs and non ANSI SQL features, they're fine! Logic in the database? We love that.

That's what ISVs and Enterprises are being told to do and that's exactly what they've done, at least the ones who couldn't see Microsoft's business angle. Now many are left to choose to either accept Microsoft's ever-increasing licensing costs or a high cost to switch.

I agree with @BrentOzar, time to find other options.




I see nothing wrong with using stored procs or non-ANSI features. You just need to know what you're getting into. The same goes for any database. Being database agnostic is great but so is actually finishing what you're working on and having it run efficiently. If DB specific features get you there and you're willing to accept the terms of being locked in then it's a sound decision.

For our product we use Postgres as the app's database and happen to use some Postgres specific features like stored procs and hstore[1]. The latter in particular is not ANSI at all. There is no equivalent at all in other databases and migrating usage of it to another DB would be a real pain. I know we're tied to Postgres and we're ok with that as it's a joy to use and let's us spend our time elsewhere.

You use database specific features because they're useful, not because you're forced to. Of course I'll concede the point that it's a bit apples and oranges to compare being "stuck" on Posgtres vs a commercial closed source stack.

[1]: http://www.postgresql.org/docs/9.2/static/hstore.html


"...so is actually finishing what you're working on and having it run efficiently."

A "finished" product is usually a dead one and efficiency is relative. You've seen that incremental improvements to the entire stack can have far greater impact than fiddling with just the storage end alone after all.

A product never actually stops evolving if it's going to stay competitive and make money. But I'd say staying with Postgres is one of the best decisions you've made. Besides being a joy, as you say, you can be fairly confident that it won't suddenly become broken, become proprietary and best of all, become an order of magnitude more expensive for the same capability.


To clarify by "finished" I meant shipping a working version of a product, not being finished with all work on the product.




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

Search: