Xata is now live

Starting today, Xata is out of private Beta!

Goodbye waiting list 👋, you can go ahead and create an account. If you like to learn by doing and want to dive in right now, we promise you’re going to have a production-ready database, including high availability, with a data model, and test data in it in a matter of minutes. Try it!

After more than a year of work and receiving and addressing feedback from over 700 developers, we are very excited to show you what we’ve been up to.

So let us take you on a quick tour.

Our mission is to take the hard data problems, solve them using the industry's best practices, and then offer them to you in the most easy-to-use way possible.

The hard data problems include running PostgreSQL at scale and with high availability, replicating the data into Elasticsearch for search and analytics, edge caching, major-version upgrades, data migrations, observability, and so on. For more details around how we abstract away this complexity, see the How it Works documentation page.

We call the type of service we’re building at Xata a Serverless Data Platform, and we think it’s the next logical evolution after Database as a Service (DBaaS). Similar to how platforms like Vercel, Netlify, or Cloudflare Pages leverage CDNs, serverless and edge functions, to host your app globally and give you a simple developer experience, Xata does the same for the data infrastructure.

When we say that we offer them to you in the most easy-to-use way possible, we mean things like:

• as serverless as it gets (see our blog post on serverless databases
• a single consistent API across multiple types of data stores (relational DB, search/analytics engine, in the future caching and queues)
• a web UI that makes working with the data easy during and after development
• ORM-like high-level clients for the most popular programming languages

Xata has a relational data model, with a strict schema (schemaful) and support for JSON-like objects. Records are grouped into tables, which are grouped into databases. Xata supports rich column types and relations between tables can be represented via link columns, which are similar to foreign keys.

A record in Xata can look something like this:

{
  "name": "John Doe",
  "email": "john@example.com",
  "age": 42,
  "address": {
    "street": "123 Main St",
    "city": "New York"
  },
  "labels": ["admin", "user"],
  "team": "rec_cdcp6a98ru583kilecog"
}

The above shows a column of type object (address) with two sub-keys (street and city). It also shows a column of type email and an array-like column (labels of type multiple).

The team column is a link column, pointing to a record in another table, similar to a foreign key. Link columns make it easy to represent relationships, see more in our Data model docs.

With the TypeScript/Javascript SDK, you can query the above record with something like this:

const users = await xata.db.Users.select(['*', 'team.*']).filter({ 'address.city': 'New York' }).getMany();

In the above, because team.* was explicitly requested, the results will return all the columns from the linked Teams table as well. Behind the scene, Xata is doing a JOIN, but we expose it in a simpler way in our APIs.

You know what’s the best part about the above? If you’re using TypeScript, both the parameters and the results are fully typed. So you can easily use auto-complete to get column names, for example, and the types are going to catch mismatches between the code and the database schema. Type safety with no effort!

You can see a lot more examples of how to use both the API and the TypeScript SDK in our API Guide.

Psst, there’s an easier way!

You can read the API guide to see all the query options, but the truth is you don’t really have to 😀. Instead, you can configure your query in the UI and then hit the “Get code snippet” button. It will give you the exact query that was executed to get the results that you see on the screen. We believe that our code snippets are not only the fastest way to develop on top of Xata but also the best way to learn Xata.

A database in Xata can have multiple branches, which are first-class citizens in the API. Branches are full logical databases that might or might not exist on the same set of physical instances. When you start a new branch from an existing one, the schema is copied, but the data is not automatically available in the new branch. As you create a development branch from a production branch, you can copy and sanitize parts of the data or initialize the branch with test data.

For each branch, we record its schema history in a list of “commits”. These commits contain operations like “add a column”, “rename a column”, “add a new table”, “delete a table”, and so on. We also record which branch is created from which. This history information allows us to create the correct migration diffs and perform the minimum set of operations required for a migration.

There are multiple benefits to having database branches, which is why they are being adopted by multiple database products recently. They:

• enable development workflows that match git-workflows, for example having a branch for development, one for staging, one for production, etc.
• enable deployment previews on platforms like Vercel and Netlify.
• enable standardized workflows for applying schema migrations safely.

The last one is particularly interesting because migrating database schemas is usually easy with small amounts of data, but becomes very painful when dealing with large amounts of data. In the NoSQL wave of DB products, this issue was avoided by going schemaless. However, not having a schema introduces its own class of problems, so lately the pendulum is swinging back toward databases with strict schemas.

Because we have control over the data model and because Xata has native concepts of migrations and migration requests, we can ensure that all supported migration types are safe and they don’t lock the database. That’s why we call our migrations zero-downtime migrations. They constrain you in what types of migrations exist, but you can have the confidence that your data model will keep working at scale.

As we have shown earlier, we store the data in PostgreSQL, but we also replicate it to Elasticsearch. This enables us to offer significantly more advanced free-text search compared to the free-text-search support from PostgreSQL. This includes:

• fuzziness control so that you can have typo tolerance in your search.
• column weights, so you can value matches in some columns more. For example, you can boost matches in the “title” column more than matches in the rest of the columns.
• numeric boosters, so you can boost records by a numeric field, for example by “rating”.
• date boosters, so you can boost records that are more recent in time.
• value boosters, so you can boost records with a particular column value, for example, by “category”.

This allows you to build the perfect search experience for your users, without having to use a different service or product and worrying about how to replicate the data.

Since relevancy tuning can be tricky business, we provide a UI so you can do it visually, see the results of it in real-time, then hit the Get Code Snippet to get the code that you need in your app.

Xata offers two ways to aggregate your data: summaries, which are executed in PostgreSQL, and aggregations, which are executed in Elasticsearch.

An example of a relatively complex visualization that can be created with the Aggregation API could be: a multi-line chart, where each line represents a movie genre, and the Y axis represents the average rating of the movies in that genre, per year. This chart can be obtained with a single aggregation request, looking something like this:

const results = await xata.db.titles.aggregate({
  "movieGenres": {
    topValues: {
      column: "genre",
      size: 50
      aggs: {
        "byReleaseDate": {
          dateHistogram: {
            column: "releaseDate",
            calendarInterval: "year",
          },
          aggs: {
            "avgRating": {
              average: {
                column: "rating"
              }
            }
          }
        }
      }
    }
  },
})

You can find more examples in the API guide. We’d don’t yet have a UI to help you build this type of aggregations, but if you know us by now, we’re going to have one soon.

With today’s public launch, it is day 0 at Xata. Our mission to simplify the way developers work with data gives us a strong focus on what features to add to the product. We believe that Xata, as a serverless data platform, is the perfect companion for full-stack frameworks like Next.js, Remix.run, SvelteKit and others.

We’re very excited about upcoming features like Edge Functions and Caching (currently in private Beta, see more here), integrations into Vercel and Netlify, global data replication, and many others. Stay tuned, there’s so much more to come.

Many DBaaS and BaaS vendors offer a free-tier plan, but usually, it doesn’t include redundancy or high availability, and it’s often “for development” only with limitations based on activity.

Our free tier is explicitly recommended for production. We want you to build your personal projects, non-profit web apps, and fun apps on top of Xata, and you shouldn’t have to pay for it. You can also freely collaborate with others and be part of multiple teams (up to 40 workspaces per user). The limitations of the service are clearly stated on the pricing page and on the limits page in the docs.

If you are a seed-stage startup, a non-profit, or you were in our Beta program, we can increase the limits further, contact us and we’d be happy to discuss. You can think of us as your team of DevOps people experts in databases.

More than that, we will be on discord to help you along the way. Make sure to say hi so we can send you some swag when you publish your work.

If you read this far but didn’t try Xata yet, you should definitely do it now! 🦋