71–80 of 162 posts
Earlier quoted context omitted.
Actually, 11 is now in Beta. If you create a new instance it is listed as an option.
I tested it just before I posted the comment (to confirm) and didn't see it listed. Maybe it depends on your account? EDIT: I'll try again. Looks like it was added April 9th https://cloud.google.com/sql/docs/postgres/create-instance
Totally wish we could upgrade but for some reason AWS have still not implemented any upgrade path for Aurora PostgreSQL other than dump and reimport despite apparently working on it for a year...
Does AWS Aurora actually use postgres or is it simply a postgres compatible API on top of their own technology?
With Aurora, the storage layer is swapped out entirely for a distributed storage engine, that I believe is based upon DynamoDB.
The wire protocol and server interface are much the same as regular Postgres, though there are some additional benefits as well as caveats as you might expect
Earlier quoted context omitted.
Out of interest ;) SQL Server is such an expensive beast, ~$15K per core, what are your reasons for prefering it over PG?
I use MS-SQL for my day job, and Postgres for personal projects. Pros of MS-SQL are mainly 1) easy integration with the universe of Microsoft dev tools, frameworks, and infrastructure, and 2) great database tooling in itself: * SSMS - SQL Server Management Studio * The MS BI stack: SSRS (reporting), SSAS (analysis), SSIS (integration)
Question from a Python web developer. (Django mainly, exploring Flask presently) For a complex web-app, would you suggest an ORM (looking at SQLAlchemy) or a custom module with hand written queries and custom methods for conversion to python objects? My app has a lot of complex queries, joins, etc. and the data-model is most likely to change quite a bit as the app nears production. I feel using an ORM is an unnecessa…
Use both. Many of the business logics are just as simple as query by id, filter/sort by a couple of columns. A smart ORM will handle fetching relationships without hitting N+1 problem For advanced queries, you can write raw SQL The way I see it, an ORM has three useful features: - A migration/seed mechanism (you will need it anyway) - A schema definition for mapping tables to object - A query builder If you feel that…
* for normal queries (select /cols from table where id etc etc) we just used plain django orm. even for weird joins, django orm makes it a lot easier than using raw sql
when we needed raw speed, we just wrote raw sql and delegated to django sql layer -- that way we leverage everything the framework has with raw sql power.
I maintain a couple of MySQL based applications. I don't really use any features outside of "standard SQL" is there a reason to switch over to Pg? I haven't used Pg before and usually default to MySQL.
At my PHP-shop company, most projects are limited to MySQL 5.7 (legacy reason, dependency reason, boss-likes-MySQL reason...). They are all handicapped by MySQL featureset, and can't update to 8 yet. If they had used Postgres some years ago, they would get: - JSON column (actually MySQL 5.6 supports it but I doubt if it's as good as Postgres) - Window functions (available in MySQL 8x only, while this has been availab…
For indexing on function expressions in particular, the workaround we use is to add a generated column and index that.
Earlier quoted context omitted.
Out of interest (SQL Server guy mainly, so only partly keep up with what other engines are doing), what changes significantly affect performance (without making changes to your own code/configuration to make use of new features) in 10.x & 11.x?
It kinda bugs me that people say "SQL Server" to mean "Microsoft SQL Server". I mean, there are other sql servers.
Earlier quoted context omitted.
> It kinda bugs me that people say "SQL Server" to mean "Microsoft SQL Server". I mean there are other sql servers. I don't mind that; sure, there are other RDBMS servers that support SQL as their main or exclusive language, but unless you are talking about ancient Sybase products (for which there is a very good reason for the shared branding) “SQL Server” is a clear, exclusive Microsoft product identity and not any…
https://en.wikipedia.org/wiki/SQL_Server Same as "FTP Server" doesn't mean proftpd, "HTTP Server" doesn't mean apache and "C compiler" doesn't mean gcc. SQL is a language. Server is a generic term. Another example: I may ask my colleague the following: "Which SQL server should we use in our new project?". Does this mean, i would like to know the edition and version of the MS SQL Server or maybe (and from my point of…
It also helps that nobody says "The SQL server is down" when their mysql instance is down. Even when using a generic term it's "the database is down"
I maintain a couple of MySQL based applications. I don't really use any features outside of "standard SQL" is there a reason to switch over to Pg? I haven't used Pg before and usually default to MySQL.
The benefits are better defaults in terms of data reliability. Hard to say if migration is worth it to you without a lot more details, but I'd definitely recommend trying it in a new project.
Where I work, we chose MySQL back in 2012 due to production quality async replication. I think (but am never sure) that that is now good in Postgres land.
PG has a lot of SQL features I'd love to use and can't. OTOH MySQL's query planner is predictably dumb, which means I can write queries and have good idea about how well (or not) they'll execute.
Earlier quoted context omitted.
It kinda bugs me that people say "SQL Server" to mean "Microsoft SQL Server". I mean, there are other sql servers.
SQL Server is a registered trademark of Microsoft at least in the US and I’m sure other jurisdictions. Using SQL Server to refer to Microsoft’s relational database product is perfectly reasonable and pretty much every will know what you mean. The generic term seems to be RDMS or some variation on that.
Earlier quoted context omitted.
$7500 per core, but only $15,000 for two cores sounds like a sweet deal though.
There are no more server CPUs with less than 6 cores though. We could happily manage with just 2 dedicated to SQL server, but you have to license all the cores you have. So 3K worth of low end hardware ends up costing you several multiples of that in licensing.