Skip to main content

4 posts tagged with "tigris"

View All Tags

· 4 min read
Ovais Tariq

Complexity to Simplicity with Tigris

Join the Tigris waitlist and be the first to try the new open-source developer data platform for your next application

Over the past year, we’ve been building a revolutionary new data platform for developers to handle all their applications’ data needs without all the data infrastructure complexity. This is the first truly open source developer data platform available with a simple yet powerful, unified API that spans search, event streaming, and transactional document store. It enables you to focus on building your applications and stop worrying about the data infrastructure.

Today we are opening up the waitlist for you to join our beta program. Tigris is focused on the needs of the developer community and committed to delivering a solution that addresses the unique needs of developers in a data driven environment. The best way for us to build a better platform is to work with our users on a daily basis.

If you are interested in helping us out please add yourself to our waitlist here. We will be providing access to the platform on a rolling basis in the coming weeks.

Why we created Tigris?

While working on the database platforms for companies like Uber, Percona and other startups, we noticed a common problem - Developers are held back by their databases.

Building modern cloud native applications often requires you to bolt on systems and infrastructure components to overcome the shortcomings of your data infrastructure that were never designed to operate in the modern ecosystem.

This means more tools to manage and deploy, and infrastructure complexity that distracts you from building your applications.

This cost of maintaining multiple different systems is not only expensive but is disruptive to development time. Time has become an extremely limited resource for developers. The more complex the environment, the more time is spent troubleshooting, learning new database languages, and maintaining various systems, instead of shipping features and building applications.

This is exactly why we built Tigris. Now developers will spend less time on tedious infrastructure management and more time on what they do best - coding and feature development.

Features to simplify your workflow

  1. Simple APIs: Quickly add data and easily retrieve or edit that data through simple and intuitive APIs.
  2. Flexible Document Model: Our JSON data structure makes it easy to map to the objects in your code while providing the schema enforcement seen in traditional databases. Furthermore, its flexibility makes it easy to evolve your data models.
  3. Zero Cost Schema Evolution: Schemas evolve in a lightweight manner without any downtime. Changes are performed in a transactional manner, take only a few milliseconds to complete and do not require a collection rebuild.
  4. Automatic Index Maintenance & Management: The system makes query tuning a thing of the past with automatic index management and maintenance, meaning you will never have to worry about slow queries due to missing indexes.
  5. Transactions: Strictly serializable isolation, and unlike some other document databases, no confusing read / write concerns to configure, and no cross-shard caveats.
  6. Event Streaming: Built-in event streaming allows you to subscribe and publish events using the same API you use to query and search data. Since data is automatically indexed, you can query all data and search through all events with ease.
  7. Global Search: Search across all your collections using full text or faceted search. All with an integrated search engine that eliminates the need to run a separate search platform and synchronize data.
  8. Cloud Native Architecture: Built as individual components that can be scaled independently to keep performance and scalability high while keeping costs low. Core data storage is built on FoundationDB, a distributed backend that enables nearly limitless scalability.
  9. Open Source: Tigris is truly open source, adhering to an Apache 2 license. Built on open source principles we’re committed to providing a secure, stable, and innovative product.
  10. Multi-tenant by default: Save on investment costs and maximize resource usage. Multi-tenancy provides the much needed flexibility to add new customers and applications quickly and easily.

If you are interested in helping us out please add yourself to our waitlist below. We will be providing access to the platform on a rolling basis in the coming weeks. If you’re selected to participate in the beta, you’ll receive an email invitation to get started.

🚀 Click here to signup for the Tigris beta and get early access!

· One min read
Ovais Tariq

We're excited to announce that Tigris Data has joined Netlify's Jamstack Innovation Fund as one of the 10 most promising Jamstack startups.

Tigris Data joins Netlify's Jamstack Innovation Fund

As the world increasingly shifts to digital-first interactions, the need for fast, reliable, and secure web applications has never been greater. The Jamstack movement is a response to this need, focused on building web applications that provide rich experiences while at the same time being easy to deploy and scale. Data is, of course, crucial to building rich experiences, and the support from Netlify will accelerate our mission to provide the fast, reliable and secure data layer that Jamstack applications need to thrive.

· 7 min read
Ovais Tariq

In our inaugural blog post Hello world, we talked about the problem of data infrastructure sprawl that, over the years, has complicated modern application development, while putting a lot of burden on the operations team who must manage, maintain and secure many different databases and technologies.

In this blog post, we’ll explain what we mean when we say "data infrastructure sprawl" by walking through a typical example, and then we’ll explain why it doesn’t have to be this way.

The standard evolution story of a modern application

Let's start by taking a look at what an application looks like at the beginning of the journey. The application is simple, it talks to a database, typically a traditional OLTP database such as Postgres, or MySQL.

Application and Database

To scale the application further and increase reliability, some of the application logic is moved to background processing. This requires introducing a message queue such as RabbitMQ or ActiveMQ. Now the application architecture looks something like this:

Application, Database and Message Queue

Over time, the application grows in popularity and more features are added. The development team starts to feel the pain of working with a relational database. They want to be able to scale reads and writes independently, so they introduce read replicas and update the application logic to split the read and write requests. This exposes the development team to infrastructure-related concerns. At the same time, it also increases the application complexity as developers now need to decide when it’s safe to read from the read replicas and when they need to query the primaries instead.

Application, Database with replicas, Message Queue

At some point, the business analysts may need to analyze the data to guide business decisions. They could do it for a while using the primary database, but eventually these requests will have to be isolated from production. One easy solution that companies adopt involves running a nightly job that exports the data out of production into a data warehouse like Redshift or BigQuery.

Application, Database with replicas, Message Queue, Data Warehouse

As the business continues to grow, so does the complexity of the application infrastructure required to support it. The developers continue to expand the application's functionality by adding full text search capabilities. They decide that introducing Elasticsearch or Solr would be best since the primary OLTP database does not have a capable search engine. The search functionality is introduced via a new microservice so that the team can iterate quickly and experiment with new technology without disrupting the existing business. The new search microservice needs to know when certain operations are performed on the primary OLTP database, so a message bus, such as Kafka, is introduced as well. Now the application architecture looks something like this:

Application, Database with replicas, Message Queue, Data Warehouse, Search

Does this look familiar? The application isn’t doing anything crazy from a technological perspective. All the team has built is a backend that can:

  1. Power CRUD operations.
  2. Provide search functionality.
  3. Exposes key business data to our analysts in a data warehouse.
  4. Allows experimentation and quick iteration in a “safe” manner that doesn’t put the entire business in jeopardy.

The backend though has become a complex distributed system with many different moving components. Each component must be deployed, configured, secured, monitored, and maintained. The team has to think about things like data replication, data consistency, availability, and scalability for each of the individual components as well.

Over time, the team starts spending less time building the functionality required to grow the business, and more time managing incidental infrastructure.

Fundamental reasons for the data infrastructure sprawl

This type of “data infrastructure sprawl” is the norm in the industry today, and justifiably so. At every point in the story above, engineering leadership made well-founded and logical architectural decisions, but the end result was high amounts of incidental complexity that made even straightforward feature development time-consuming. But at Tigris, we don’t think it has to be this complicated. Users are forced into this situation because the open source marketplace is filled with rich and powerful building blocks, but it’s lacking in holistic solutions.

Most open source databases today take a narrow view of the world:

  • They have rich query functionality, but they can’t scale beyond a single node. Or, they can scale horizontally, but push all the hard correctness and consistency problems to the application developers.
  • They can function as your primary data store, or they support rich full text search functionality, but rarely both.
  • Multi-tenancy and isolation between workloads are an afterthought or not present at all. Applications can’t be logically isolated while sharing the same underlying “database platform” in a safe manner. Often the database itself is “unsafe by default” and won’t provide so much as a warning before happily performing a full table scan every time someone navigates to your home page.

What should a modern database look like?

We believe that, “Correctness, reliability, and user experience over raw performance” is a good guiding principle that, if followed, would lead to the development of a modern database platform that could keep the data infrastructure sprawl at bay.

This of course sounds great on paper, but prioritizing user experience over micro-benchmarks is not how most modern database companies try to differentiate themselves.

Database Comparisons Today

What most database comparisons look like today

This may seem obvious, but building a holistic database platform that can keep data architectural sprawl at bay means that the developers of this new system must take a principled stand to always do right by the user instead of the benchmarks. This is a very difficult thing to do in the current competitive climate that is dominated by benchmark-obsessed marketing material. The recent controversy between Snowflake and Databricks is a great example of this. It’s much easier to quantify rows/s/core than it is to quantify (a) sleepless nights, (b) apologies issued to your customers, and (c) developer productivity.

Business Value Created

Product Success

What most database comparisons should look like

So what would a database that helps customers maximize business value instead of micro-benchmarks look like? At Tigris, it boils down to a system with the following characteristics:

  1. A flexible document model that enables developers to model data in a way that best suits their applications’ needs. The data model should also be easy to evolve, and schema changes should be as simple and painless as regular feature development.
  2. Simple and intuitive APIs that allow developers to quickly insert and retrieve data while continuing to use their preferred programming language - no new database query language to learn.
  3. Strictly serializable isolation by default. This ensures that developers never need to think about how transactions work or what their limitations are, nor do they need to configure things like read and write concerns or transaction isolation levels.
  4. “Distributed by default” with no painful transition point when the needs of the application begin to exceed the capabilities of a single node. Sharding should also be transparent, and the system should ensure that the database scales seamlessly as the application traffic increases, while core operations such as transactions do not have any restrictions in terms of the records or shards that can participate.
  5. Multi-tenant by default so that learning how to deploy, operate, and secure a single database technology is enough for the majority of the applications.
  6. An integrated search engine that provides developers with real-time search functionality eliminating the need to run a separate search platform and synchronize data.
  7. Built-in low latency replication to cloud data lakes for OLAP workloads that eliminates the need for developers to configure, track, and maintain separate ETL processes.

This is exactly what we’re building with Tigris! Stay tuned for future posts where we’ll discuss in detail how we’re leveraging open source technology like FoundationDB to build a rock solid and intuitive database platform in record time. We’re also hiring!

· 3 min read
Ovais Tariq
Himank Chaudhary
Yevgeniy Firsov

We're excited to announce the launch of Tigris Data, a company on the mission of simplifying data management for developers.

Over the years, data has become increasingly complex and difficult to manage. Developers have had their lives made exponentially more difficult due in large part to all these different technologies, data models, APIs, and databases they're expected to put together to build modern applications.

The database sprawl also puts a lot of pressure on operations teams, who must manage, maintain and secure these different databases and technologies. Then there is the onerous task of operationalizing these databases across multiple different cloud platforms.

Complexity to Simplicity with Tigris

We have personally experienced the pain and financial cost from the complexity. We want to make it easier for you to work with data by providing you with a unified database that helps quickly and easily structure the data in any way the application requires while providing you with one consistent experience across a broad set of workloads.

Furthermore, we are building the database to be open source, so you can avoid vendor lock-in and have the transparency to be sure that the product will continue to evolve and improve over time. Additionally, it enables anyone to be able to contribute improvements and extensions to the codebase. All-in-all being open source makes the product more accessible, robust, and secure for everyone.

We're grateful to have assembled an amazing team that is passionate about simplifying data management for developers. Our team has a wealth of experience in data management, distributed systems, and databases. We're excited to bring our knowledge and experience to bear on the problem of data management.

We're also proud to announce that in December of last year, we successfully raised a seed round led by Basis Set with additional funding from General Catalyst and many individual angels including founders at technology unicorns.

Now we're well on our way to a preview of the Tigris database later this year!

If you're interested in learning more about Tigris Data or staying up-to-date on our progress, subscribe to our mailing list or follow us on Twitter.

The founders

Before starting Tigris Data, the founders, Ovais, Himank, and Yevgeniy, spent almost six years working closely together at Uber. They developed and operated Uber's storage infrastructure, leading projects like Docstore, Herb, and DBEvents.

Their experiences have given them a lot of important lessons. They've learned about the importance of making architectural choices that can scale, establishing efficiency as a core principle, hiring the right talent, and cultivating a culture that supports diversity, innovation, and growth.