Need advice about which tool to choose?Ask the StackShare community!
Microsoft SQL Server vs Serverless: What are the differences?
Introduction
In this article, we will discuss the key differences between Microsoft SQL Server and Serverless.
Scalability: Microsoft SQL Server is a traditional relational database management system (RDBMS) that requires provisioning and managing resources to handle scalability. On the other hand, Serverless databases automatically scale up and down based on the workload, eliminating the need for manual provisioning and management.
Pricing Model: Microsoft SQL Server typically follows a traditional licensing model where users need to purchase and manage licenses based on the number of cores, with additional charges for features and support. In contrast, Serverless databases often follow a pay-per-use model, where users only pay for the resources consumed during query execution.
Infrastructure Management: With Microsoft SQL Server, users are responsible for managing and maintaining the underlying infrastructure, including servers, operating systems, patching, backups, etc. In the case of Serverless databases, most of the infrastructure management tasks are abstracted away, allowing users to focus solely on data and applications.
Automatic Scaling: In Microsoft SQL Server, scaling the database to handle increased workloads often requires manual intervention, such as adding more servers or increasing resource allocations. Serverless databases automatically handle scalability by dynamically provisioning resources based on demand, ensuring optimal performance without user intervention.
Query Optimization: Microsoft SQL Server incorporates various query optimization techniques, such as indexing, caching, and query plan analysis, to enhance query performance. Serverless databases also employ similar optimization techniques but may have different mechanisms tailored to their specific implementation.
Pay-Per-Use: While Microsoft SQL Server generally has a fixed cost regardless of usage, Serverless databases charge users based on the actual resources consumed during query execution. This pay-per-use model can be more cost-effective for sporadic or unpredictable workloads where resources are only allocated when needed.
In Summary, Microsoft SQL Server is a traditional RDBMS that requires manual provisioning, management, and scaling, whereas Serverless databases automatically handle scalability, have a pay-per-use pricing model, and abstract away infrastructure management tasks, making them more flexible and cost-effective.
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.
Hi Erin,
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.
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.
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,
- 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.
Regards,
I recommend Postgres as well. Superior performance overall and a more robust architecture.
When adding a new feature to Checkly rearchitecting some older piece, I tend to pick Heroku for rolling it out. But not always, because sometimes I pick AWS Lambda . The short story:
- Developer Experience trumps everything.
- AWS Lambda is cheap. Up to a limit though. This impact not only your wallet.
- If you need geographic spread, AWS is lonely at the top.
Recently, I was doing a brainstorm at a startup here in Berlin on the future of their infrastructure. They were ready to move on from their initial, almost 100% Ec2 + Chef based setup. Everything was on the table. But we crossed out a lot quite quickly:
- Pure, uncut, self hosted Kubernetes — way too much complexity
- Managed Kubernetes in various flavors — still too much complexity
- Zeit — Maybe, but no Docker support
- Elastic Beanstalk — Maybe, bit old but does the job
- Heroku
- Lambda
It became clear a mix of PaaS and FaaS was the way to go. What a surprise! That is exactly what I use for Checkly! But when do you pick which model?
I chopped that question up into the following categories:
- Developer Experience / DX 🤓
- Ops Experience / OX 🐂 (?)
- Cost 💵
- Lock in 🔐
Read the full post linked below for all details
Pros of Microsoft SQL Server
- Reliable and easy to use139
- High performance101
- Great with .net95
- Works well with .net65
- Easy to maintain56
- Azure support21
- Always on17
- Full Index Support17
- Enterprise manager is fantastic10
- In-Memory OLTP Engine9
- Easy to setup and configure2
- Security is forefront2
- Great documentation1
- Faster Than Oracle1
- Columnstore indexes1
- Decent management tools1
- Docker Delivery1
- Max numar of connection is 140001
Pros of Serverless
- API integration14
- Supports cloud functions for Google, Azure, and IBM7
- Lower cost3
- 3. Simplified Management for developers to focus on cod1
- Auto scale1
- 5. Built-in Redundancy and Availability:1
- Openwhisk1
Sign up to add or upvote prosMake informed product decisions
Cons of Microsoft SQL Server
- Expensive Licensing4
- Microsoft2
- Data pages is only 8k1
- Allwayon can loose data in asycronious mode1
- Replication can loose the data1
- The maximum number of connections is only 14000 connect1
