Memcached vs Microsoft SQL Server

Need advice about which tool to choose?Ask the StackShare community!

Memcached

6.8K
4.9K
+ 1
470
Microsoft SQL Server

17.3K
12.8K
+ 1
539
Add tool

Memcached vs Microsoft SQL Server: What are the differences?

Developers describe Memcached as "High-performance, distributed memory object caching system". Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. On the other hand, Microsoft SQL Server is detailed as "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.

Memcached and Microsoft SQL Server can be primarily classified as "Databases" tools.

"Fast object cache", "High-performance" and "Stable" are the key factors why developers consider Memcached; whereas "Reliable and easy to use", "High performance" and "Great with .net" are the primary reasons why Microsoft SQL Server is favored.

Memcached is an open source tool with 8.99K GitHub stars and 2.6K GitHub forks. Here's a link to Memcached's open source repository on GitHub.

Facebook, Instagram, and Dropbox are some of the popular companies that use Memcached, whereas Microsoft SQL Server is used by Stack Exchange, Intuit, and MIT. Memcached has a broader approval, being mentioned in 755 company stacks & 267 developers stacks; compared to Microsoft SQL Server, which is listed in 478 company stacks and 443 developer stacks.

Advice on Memcached and Microsoft SQL Server

I have a project (in production) that a part of it is generating HTML from JSON object normally we use Microsoft SQL Server only as our main database. but when it comes to this part some team members suggest working with a NoSQL database as we are going to handle JSON data for both retrieval and querying. others replied that will add complexity and we will lose SQL Servers' Unit Of Work which will break the Atomic behavior, and they suggest to continue working with SQL Server since it supports working with JSON. If you have practical experience using JSON with SQL Server, kindly share your feedback.

See more
Replies (2)
TwoBySea

I agree with the advice you have been given to stick with SQL Server. If you are on the latest SQL Server version you can query inside the JSON field. You should set up a test database with a JSON field and try some queries. Once you understand it and can demonstrate it, show it to the other developers that are suggesting MongoDB. Once they see it working with their own eyes they may drop their position of Mongo over SQL. I would only seriously consider MongoDB if there was no other SQL requirements. I wouldn't do both. I'd be all SQL or all Mongo.

See more
Kevin Deyne
Principal Software Engineer at Accurate Background · | 2 upvotes · 22.4K views
Recommends

I think the key thing to look for is what kind of queries you're expecting to do on that JSON and how stable that data is going to be. (And if you actually need to store the data as JSON; it's generally pretty inexpensive to generate a JSON object)

MongoDB gets rid of the relational aspect of data in favor of data being very fluid in structure.

So if your JSON is going to vary a lot/is unpredictable/will change over time and you need to run queries efficiently like 'records where the field x exists and its value is higher than 3', that's a great use case for MongoDB.

It's hard to solve this in a standard relational model: Indexing on a single column that has wildly different values is pretty much impossible to do efficiently; and pulling out the data in its own columns is hard because it's hard to predict how many columns you'd have or what their datatypes would be. If this sounds like your predicament, 100% go for MongoDB.

If this is always going to be more or less the same JSON and the fields are going to be predictably the same, then the fact that it's JSON doesn't particularly matter much. Your indexes are going to approach it similar to a long string.

If the queried fields are very predictable, you should probably consider storing the fields as separate columns to have better querying capabilities. Ie if you have {"x":1, "y":2}, {"x":5, "y":6}, {"x":9, "y":0} - just make a table with an x and y column and generate the JSON. The CPU hit is worth it compared to the querying capabilities.

See more

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:

  1. I need to use either MySQL or PostgreSQL on a Linux based OS. Which would be better for this application?
  2. I have not dealt with a sound based data type before. How do I store that and put it in a table? Thank you.
See more
Replies (6)

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.

See more
Aaron Westley
Recommends
PostgreSQLPostgreSQL

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.

See more
Julien DeFrance
Principal Software Engineer at Tophatter · | 3 upvotes · 259.5K views
Recommends
Amazon AuroraAmazon Aurora

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.

See more
Christopher Wray
Web Developer at Soltech LLC · | 3 upvotes · 259.9K views

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!

See more
Recommends
PostgreSQLPostgreSQL

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,

See more
Klaus Nji
Staff Software Engineer at SailPoint Technologies · | 1 upvotes · 259.6K views
Recommends
PostgreSQLPostgreSQL

I recommend Postgres as well. Superior performance overall and a more robust architecture.

See more
Decisions about Memcached and Microsoft SQL Server
Asif Khan
Software Development Engineer at Stier Solution Private Limited · | 10 upvotes · 47.4K views

Easy to start, lightweight and open source.

When I started with PHP, MySQL was everywhere so this is how I started with it. I am no expert in databases but I started learning joins, stored procedures, triggers, etc. with MySQL.

Recently used it in one of my projects - Picfam.com with Node.js + Express backend

See more
Josip Užarević
Senior frontend developer · | 6 upvotes · 58K views

Needed to transform intranet desktop application to the web-based one, as mid-term project. My choice was to use Django/Angular stack - Django since it, in conjunction with Python, enabled rapid development, an Angular since it was stable and enterprise-level framework. Deadlines were somewhat tight since the project to migrate was being developed for several years and had a lot of domain knowledge integrated into it. Definitely was good decision, since deadlines was manageable, juniors were able to enter the project very quickly and we were able to continuously deploy very well.

See more
Get Advice from developers at your company using StackShare Enterprise. Sign up for StackShare Enterprise.
Learn More
Pros of Memcached
Pros of Microsoft SQL Server
  • 138
    Fast object cache
  • 128
    High-performance
  • 90
    Stable
  • 65
    Mature
  • 33
    Distributed caching system
  • 11
    Improved response time and throughput
  • 3
    Great for caching HTML
  • 2
    Putta
  • 139
    Reliable and easy to use
  • 102
    High performance
  • 95
    Great with .net
  • 65
    Works well with .net
  • 56
    Easy to maintain
  • 21
    Azure support
  • 17
    Always on
  • 17
    Full Index Support
  • 10
    Enterprise manager is fantastic
  • 9
    In-Memory OLTP Engine
  • 2
    Security is forefront
  • 1
    Columnstore indexes
  • 1
    Great documentation
  • 1
    Faster Than Oracle
  • 1
    Decent management tools
  • 1
    Easy to setup and configure
  • 1
    Docker Delivery

Sign up to add or upvote prosMake informed product decisions

Cons of Memcached
Cons of Microsoft SQL Server
  • 2
    Only caches simple types
  • 4
    Expensive Licensing
  • 2
    Microsoft

Sign up to add or upvote consMake informed product decisions

- No public GitHub repository available -

What is Memcached?

Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

What is Microsoft SQL Server?

Microsoft® SQL Server is a database management and analysis system for e-commerce, line-of-business, and data warehousing solutions.

Need advice about which tool to choose?Ask the StackShare community!

Jobs that mention Memcached and Microsoft SQL Server as a desired skillset
What companies use Memcached?
What companies use Microsoft SQL Server?
See which teams inside your own company are using Memcached or Microsoft SQL Server.
Sign up for StackShare EnterpriseLearn More

Sign up to get full access to all the companiesMake informed product decisions

What tools integrate with Memcached?
What tools integrate with Microsoft SQL Server?

Sign up to get full access to all the tool integrationsMake informed product decisions

Blog Posts

Dec 22 2020 at 9:26PM

Pinterest

Amazon EC2MemcachedC lang+4
10
2483
Jun 6 2019 at 5:11PM

AppSignal

RedisRubyKafka+9
15
1273
GitHubDockerReact+17
35
33776
GitHubPythonNode.js+47
53
70954
JavaScriptGitHubNode.js+26
19
4787
JavaScriptGitHubPython+42
53
20832
What are some alternatives to Memcached and Microsoft SQL Server?
Redis
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams.
Ehcache
Ehcache is an open source, standards-based cache for boosting performance, offloading your database, and simplifying scalability. It's the most widely-used Java-based cache because it's robust, proven, and full-featured. Ehcache scales from in-process, with one or more nodes, all the way to mixed in-process/out-of-process configurations with terabyte-sized caches.
Varnish
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.
Hazelcast
With its various distributed data structures, distributed caching capabilities, elastic nature, memcache support, integration with Spring and Hibernate and more importantly with so many happy users, Hazelcast is feature-rich, enterprise-ready and developer-friendly in-memory data grid solution.
MongoDB
MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding.
See all alternatives