How Database Vendors Can Make It Easy For New Users To Get Started On Their Platform

New And Improved

There are a lot of databases out there. All of them, of course, better than their competitors.

Faster, easier, cloudier, smarter, shardier. Blah blah blah. Sounds great! But how do you get new users to try your product and make any reasonable assessment of it?

Not everyone comes to the table with a bunch of data they can jam right in and get partying with.

Worse, they might be on a platform where exporting their data to use on your platform (because, let’s face it, no two products have the same backup format) is a real and complete pain.

The number of hurdles that users face just getting to the point where they can make an assessment of your product are pretty huge.

Let’s talk about how you can make that easier.

Working Data Sets

Stack Overflow provides public access to their data sets, both as XML dumps, and a web interface.

I’m not saying that their relational data makes sense for every system out there, but it’s a big data set that’s good for analysis.

If you own a database product, you could:

  • Grab the dumps and turn them into a format that makes sense for your platform
  • Have a hosted playground for new users to run queries against interactively

This helps potential new customers get comfortable with the inevitable proprietary syntax, gauge query efficiency.

Microsoft, for all its silliness, gives SQL Server users a couple different sample databases to work off of. They even update them for new versions to show off all the new memes features they’ve added.

They even have a free developer edition of the product that you can install and run with pretty quickly. You don’t need this if your product is all cloud-based, but you get the idea.

Hands-down, the most annoying part of testing any database platform, is getting reasonable data to test against in there.


If you are an installer-based life form, and your database as a lot of settings that might matter for performance and reliability, or uses a specific OS, you should consider having a few different VM images available for download.

This lets you easily distribute a golden copy of an ideal environment for your product, with the OS, database, and data all packed together.

Oracle does this, and for the short time I had to experiment with some stuff on their platform, it was incredibly handy.

If you don’t want to go this route, because you don’t quite have Oracle money, being a fledgling database product, have a dedicated install and config page:

  • Recommended hardware
  • OS version
  • Database install steps
  • Any additional dependencies
  • Recommended database configurations
  • Where to get ample sample data to play with

While we’re talking about sample data, why not have a few different sizes of data? Not everyone wants to set up a 64 core, 2TB of RAM virtual machine just to mess with a petabyte set of time series data.

Have some small, medium, large, and extra large sets available for testing.

Sure, prospective clients might opt for small and medium, but the folks you want to evangelize your product are going to love you for having bigger data sets to show more complex problems and solutions.

If part of the sell for your product is how great data ingestion is, have data ready to ingest based on whatever format you excel at, even if it’s Excel files.

More likely it’s csv, parquet, json, or uh… something.


A lot of folks are used to having more than a command line to interact with their database.

Postgres has pgAdmin, Oracle has SQL Developer, Microsoft has SQL Server Management Studio and Azure Data Studio, and there are many third party tools that can connect to a variety of platforms, too.

Writing large, complex queries in a CLI is a drag. It might be great for administration, and simple stuff, but correcting syntax errors in them is like threading needles blindfolded.

You may not want to build a whole bunch of tooling up front for developers to work in, but a lightweight browser-based tool with a “run” button can go a long way.

Take db<>fiddle as an example. You can’t do any database management with it, but you can pretty much fully interact with the database by sending queries in, the way a developer would write and test queries.


I love playing with other databases, but I do not love all the foreplay it takes just to get moving with one.

The more things are different about your platform — and those differences may be spectacular — the harder it is to lure away folks who are inexperienced with the stack you’ve chosen.

You might even have an amazing sales tech team who will come in and do a lot of the heavy lifting for prospective clients, but some companies out there want to do a test run before investing a lot of time and getting hourly check-ins from sales reps about how things are going and when the contract will get signed.

That also ignores one of the most powerful segments of any database community: the developers who will build content around your product, and go out in the world to blog, present, and develop training content.

Thanks for reading!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that, and need to solve database performance problems quickly. You can also get a quick, low cost health check with no phone time required.