ovaistariq

That depends on what you would qualify as successful :) It’s early days but AlgoraTV is seeing a lot of success in my opinion. I am generally happy to support folks in however way I can.

Tigris CEO and co-founder here. Unless it is in tens of PB range we don’t count it as extraordinary. And even then the goal is not to tax for bandwidth.

I am curious why this sounds dangerous. Data is still getting persisted to storage. It’s just a different architecture where compute and storage are not colocated on the same machine.

There are valid reasons for extending and redoing some parts of the API. I will give you one example. Suppose you want to extend list objects to support ordering by last modified or you want to support filtering of objects by user metadata. Right now doing this is quite clunky via headers.

I appreciate the callout to Tigris. Now it’s super easy to use Tigris with Supabase for all those files.

S3 uses HTTP protocol for communication between client and server. The `s3://` paths make it seem like it’s a protocol but that’s just a way to represent the path on the s3 client to differentiate it from a local file path.

S3 is not known for performing well with such small files. Is this primarily how your dataset on S3 looks like?

Supporting an existing API provides interoperability which is beneficial for the users. So that way if there is a better storage service it’s easier to adopt it. However, the S3 API compatibility can be a hindrance when you want to innovate and provide additional features and functionality. In our case, providing additional features [1] [2] while continuing to be S3 API compatible has forced us to rely on custom headers.

[1] https://www.tigrisdata.com/docs/objects/conditionals/ [2] https://www.tigrisdata.com/docs/objects/caching/#caching-on-...

Yes we are based on FoundationDB. We pivoted from OLTP database to a lower level product as we found that it makes more sense to innovate at the storage infra layer. There is lot of innovation already happening at the higher level database layer.

And we don’t charge for egress to internet.

If you are looking for an active-active multi-region read-anywhere write-anywhere object storage service then you would choose Tigris over R2 :)

There is zero $$ to pay for egress to internet: https://www.tigrisdata.com/docs/pricing/

Believe me, there is a lot for us to write about. And we will be publicly posting about the various architecture choices we have made.

Hi, co-founder of Tigris here. There is a key difference between Tigris and a CDN. Tigris doesn't simply provide read caching like CloudFront. It allows what I call dynamic caching, i.e., you can literally update the object anywhere in the world, and any cached versions of the objects will be updated. So, I think of Tigris simply as a global object storage service, and the fact that it has caching built-in is more to provide fast performance and low latency than simply to mimic CDN behavior. But if you want to build a CDN, Tigris makes it trivial for a single developer to build a CDN.

We have posted a few straightforward articles comparing Tigris to Mongo. As you can see given the popularity of this post, we wrote it to show how Tigris would fit in an *ERN stack.

Indeed, Go needs a batteries-included framework. Hoping for Pushup to fill the gap.

A commentary on the WSJ post featuring Dara driving and delivering for the first time in his tenure.

This was a common practice during Travis' time but was abandoned with the arrival of a new CEO. Seeing him dogfooding the product is nice, but that shouldn't have taken six years.

Having many point solutions is problematic from a cost and complexity standpoint. General purpose solutions that would work for 80% of your use cases would be better long term. Having said that, I don’t think Postgres can be used as a general purpose solution to cover vector search, full text search and NoSQL use cases. The best general purpose solution would expose a unified API but under the hood use different storage engines to support these diverse vector search and full text search use cases.

How would you compare yourself to PostHog?

I think, in the long run, AI will have a positive impact on education for kids. But I agree that we have to start by being skeptical about it because it is still being determined whether the effect will be positive or negative with the current state of AI tools.

In this post, we explore modeling one-to-many relations. We'll look at two ways to implement one-to-many relations. The first uses an embedded pattern, and the second uses a separate collection with a relation field. We will also look at when using either of these designs is best.

Continuous backups and quickly restoring data are fundamentally important for any production-grade database platform. As we are using FoundationDB as the persistence layer for Tigris, this means having continuous backups in place for it. This post describes how backups work in FoundationDB and how to setup it up reliably.

The MongoDB Shell, mongosh, is one of the standard tools used to interact with MongoDB deployments. In this post, I will demonstrate using mongosh with Tigris.

You will see that you do not have to create a MongoDB Atlas cluster. m1k.preview.tigrisdata.cloud is a serverless deployment we will use. It has built-in automatic database sharding, meaning that, unlike MongoDB Atlas, you must never worry about sharding or shard keys, and the data distribution is automatically handled.

Update: We now have a hosted version available so that you can try out the MongoDB compatibility with any programming language. You can see the updated code here: https://github.com/tigrisdata-community/go-mongo-quickstart/...

Awesome. Would love to hear your feedback once you have tried it out.

One of our major goals in building Tigris was to provide an open source cloud-native alternative to MongoDB Atlas! We love the documented-oriented programming model that MongoDB provides, which makes it easier for application developers to manage their data. But we also think there is a need for an architecture refresh, which requires the database platform to be rebuilt from the ground up.

Our design choices at Tigris, such as composable architecture, focus on strong data consistency, automatic data sharding, and being Kubernetes-native, enable the needed modernization and makes for a much more cost-efficient, resilient, and DevOps-friendly experience.

Check out the blog post below demonstrating performing CRUD operations on Tigris using the official Go driver for MongoDB. Thanks to our partner FerretDB for working with us on enabling compatibility with MongoDB's wire protocol.

This RFC describes the data model and index management for building and querying secondary indexes on FoundationDB.

I am Co-Founder/CEO at Tigris Data and the author of this article.

Here I talk about the increased complexity of data infrastructure these days. How this idea about a specific toolset or component for a particular use-case has become the norm. And there has been a "gold" rush for infrastructure companies to stake a place in this new landscape, creating new tools and resulting in increasingly complex architectures.

We need to rethink what a data platform should look like. It has to be one that removes boilerplate and gives developers the ability to just be software developers and not DevOps.

I am focusing more on newer applications at this point than existing applications that need to be migrated over. What if you build a new app where the interface with your data is simple? You have CRUD APIs that you integrate directly with the app. Your app needs full-text search capabilities, and it comes out of the box. You don't have to spin up ES and figure out the data shipping story. What if you are building an async processing flow and you simply have to define your event handlers? The async pipeline gets built up for you automatically and the event handlers are executed based on your business logic. If I am able to provide all of this abstraction to you, then suddenly you are not just 20% productive, you are 100% more productive. Because instead of doing DevOpsy stuff you ended up focusing purely on your application code.

That's what we are looking to achieve with Tigris.

What would you have liked to see differently in the article? More explanation? More examples? I would have written a more technical article, but it probably wouldn't have been the best fit for ComputerWeekly.

I think if you look at traditional databases, yes SQL is the API interface that you use to connect to them. SQL is great for adhoc analysis of data and makes perfect sense when you are writing your data warehouse jobs.

But when you are building an application you would not be writing raw SQL queries, instead, you would be using some kind of a mapping layer (ORM) that can help map the constructs you use during application development to SQL queries. Furthermore, if we look beyond simple CRUD operations and look at other data-related functionality that you might need in your application - search, pub/sub data to an event stream, SQL would most likely not be the interface that you choose because it would be cumbersome.

That's the point I am trying to make, that we need to look at the database technologies from an application developer's perspective and provide APIs that work well in their workflow, something that naturally fits within their code. SQL isn't that API.

I am the Co-Founder/CEO of https://www.tigrisdata.com/ and the author of this post where I discuss the API-driven approach for databases.

We, as developers, love APIs because it means we can concentrate on business logic and hand over other services to others. For example, if the app needs payment processing support, why build my own when I can integrate Stripe through its API?

We need to bring the same API-driven approach to databases as well. But it is not just a matter of putting an API layer in front of every database we have. We need to consolidate the everyday database operations such as CRUD, Search and Event Streaming down to a single API layer. This can only be achieved through a cohesively built platform.