Microsoft SQL Server vs PostGIS: What are the differences?
Microsoft SQL Server: A relational database management system developed by Microsoft. Microsoft® SQL Server is a database management and analysis system for e-commerce, line-of-business, and data warehousing solutions; PostGIS: Open source spatial database. PostGIS is a spatial database extender for PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL.
Microsoft SQL Server belongs to "Databases" category of the tech stack, while PostGIS can be primarily classified under "Database Tools".
"Reliable and easy to use" is the primary reason why developers consider Microsoft SQL Server over the competitors, whereas "De facto GIS in SQL" was stated as the key factor in picking PostGIS.
PostGIS is an open source tool with 636 GitHub stars and 242 GitHub forks. Here's a link to PostGIS's open source repository on GitHub.
According to the StackShare community, Microsoft SQL Server has a broader approval, being mentioned in 470 company stacks & 425 developers stacks; compared to PostGIS, which is listed in 53 company stacks and 14 developer stacks.
I am a Microsoft SQL Server programmer who is a bit out of practice. I have been asked to assist on a new project. The overall purpose is to organize a large number of recordings so that they can be searched. I have an enormous music library but my songs are several hours long. I need to include things like time, date and location of the recording. I don't have a problem with the general database design. I have two primary questions:
- I need to use either MySQL or PostgreSQL on a Linux based OS. Which would be better for this application?
- I have not dealt with a sound based data type before. How do I store that and put it in a table? Thank you.
Honestly both databases will do the job just fine. I personally prefer Postgres.
Much more important is how you store the audio. While you could technically use a blob type column, it's really not ideal to be storing audio files which are "several hours long" in a database row. Instead consider storing the audio files in an object store (hosted options include backblaze b2 or aws s3) and persisting the key (which references that object) in your database column.
Hi Erin, Chances are you would want to store the files in a blob type. Both MySQL and Postgres support this. Can you explain a little more about your need to store the files in the database? I may be more effective to store the files on a file system or something like S3. To answer your qustion based on what you are descibing I would slighly lean towards PostgreSQL since it tends to be a little better on the data warehousing side.
Hey Erin! I would recommend checking out Directus before you start work on building your own app for them. I just stumbled upon it, and so far extremely happy with the functionalities. If your client is just looking for a simple web app for their own data, then Directus may be a great option. It offers "database mirroring", so that you can connect it to any database and set up functionality around it!
Hi Erin! First of all, you'd probably want to go with a managed service. Don't spin up your own MySQL installation on your own Linux box. If you are on AWS, thet have different offerings for database services. Standard RDS vs. Aurora. Aurora would be my preferred choice given the benefits it offers, storage optimizations it comes with... etc. Such managed services easily allow you to apply new security patches and upgrades, set up backups, replication... etc. Doing this on your own would either be risky, inefficient, or you might just give up. As far as which database to chose, you'll have the choice between Postgresql, MySQL, Maria DB, SQL Server... etc. I personally would recommend MySQL (latest version available), as the official tooling for it (MySQL Workbench) is great, stable, and moreover free. Other database services exist, I'd recommend you also explore Dynamo DB.
Regardless, you'd certainly only keep high-level records, meta data in Database, and the actual files, most-likely in S3, so that you can keep all options open in terms of what you'll do with them.
- Coming from "Big" DB engines, such as Oracle or MSSQL, go for PostgreSQL. You'll get all the features you need with PostgreSQL.
- Your case seems to point to a "NoSQL" or Document Database use case. Since you get covered on this with PostgreSQL which achieves excellent performances on JSON based objects, this is a second reason to choose PostgreSQL. MongoDB might be an excellent option as well if you need "sharding" and excellent map-reduce mechanisms for very massive data sets. You really should investigate the NoSQL option for your use case.
- Starting with AWS Aurora is an excellent advise. since "vendor lock-in" is limited, but I did not check for JSON based object / NoSQL features.
- If you stick to Linux server, the PostgreSQL or MySQL provided with your distribution are straightforward to install (i.e. apt install postgresql). For PostgreSQL, make sure you're comfortable with the pg_hba.conf, especially for IP restrictions & accesses.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Microsoft SQL Server?
What is PostGIS?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We've always counted on SQL Server as our database backend. It has served us well over the years. It isn't the cheapest part of our stack, but with the plethora of tools provided by 3rd parties, we have found an incredible and scalable method of keeping our data available and easy to maintain.
Defacto, industry standard for backend relational databases. Entity Framework makes designing, migrating & maintaining SQL Server databases a breeze. LocalDB is especially helpful during development.
Our core systems that we integrate with are using SQL Server 2012 / 2016 database servers. We use database views on core system databases to help build our domain model.
Main transactional database. SQL Server 2012 Enterprise with AlwaysOn Availability Groups for high availability and disaster recovery.
PostGIS makes it easy (and fast) to do geographic queries, such as nearest-neighbor and bounding box queries.
Backend for weather forecast data that Geoserver queries to build updated weather maps
Managing script output and input, as well as data cleansing.