[HN Gopher] Show HN: Tigris - open-source developer data platfor...
       ___________________________________________________________________
        
       Show HN: Tigris - open-source developer data platform for your next
       app
        
       Tigris is the first truly open source developer data platform 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.
        
       Author : ovaistariq
       Score  : 42 points
       Date   : 2022-09-20 17:47 UTC (5 hours ago)
        
 (HTM) web link (docs.tigrisdata.com)
 (TXT) w3m dump (docs.tigrisdata.com)
        
       | anigbrowl wrote:
       | Build out the overview with some case studies. If I am a first
       | time cloud builder at the 'what should I use...' stage - which
       | seems to be a target market for you - then _I don 't know what I
       | don't know_.
       | 
       | Right now your marketing speaks to people who have already
       | implemented something across multiple different platforms - but
       | having learned all that they're probably more willing to accept
       | the marginal cost of maintenance than to abandon the time and
       | effort already invested in setting it all up.
       | 
       | Building from scratch is a much easier and more pleasant decision
       | than migrating. So you'll gain more users from people who want an
       | accessible infrastructure experience that can grow with their
       | (presently unknown) needs than with grizzled veterans - who might
       | prefer just demanding a larger budget or more hires for
       | infrastructure on a future project than learning a new technology
       | that will render their previous knowledge obsolete.
       | 
       | Your short intro video kind of addresses this, but shows your
       | example developer deploying her app and then 5 different
       | infrastructure platforms with zero effort - she doesn't care
       | about the problem until it comes to the boring maintenance stage.
       | A lot of people would take away that the market leading
       | technologies are super-easy to deploy and that they can just hire
       | someone to do the maintenance while they focus on product or the
       | business side. (Also, the music doesn't match the visual story at
       | all and feels cringey - again, not the emotional impression you
       | want to create.)
       | 
       | In general, people will go with whatever the default tool is
       | because it's socially proven and there will be a big community of
       | prior users who can help them through the teething problems. And
       | there's a sense that the right tool for the right job is usually
       | better than a do-everything tool. So you need to show where the
       | pain points are early in the process of cloud deployment - when
       | your target user is figuring out what infrastructure they need,
       | and why.
        
         | Volundr wrote:
         | > I don't know what I don't know.
         | 
         | This probably describes me. Reading over the linked
         | documentation it's not clear to me how this is different from
         | couchdb or any number of other document databases that work
         | over http.
        
           | ovaistariq wrote:
           | Does this explain it in a better way:
           | https://docs.tigrisdata.com/overview/features
        
         | VyseofArcadia wrote:
         | > Build out the overview with some case studies. If I am a
         | first time cloud builder at the 'what should I use...' stage -
         | which seems to be a target market for you - then I don't know
         | what I don't know.
         | 
         | >Right now your marketing speaks to people who have already
         | implemented something across multiple different platforms
         | 
         | This seems to be a pretty big gap in marketing across the
         | industry. Everything is either utterly meaningless market-
         | speak[0] or targeted at experts.
         | 
         | [0] The sheer number of products marketing themselves as one-
         | size-fits-all "solutions" without ever bothering to define the
         | problem...
        
       | masukomi wrote:
       | after reading the front page i honestly have no clue what this
       | is, but i'm reasonably certain that part of it is a document db.
       | the quickstart seem to imply that i throw JSON at it via APIs and
       | that that ends up in the implied db. The quickstart is also all
       | about "hey DB stuff"
       | 
       | so, now i think it's... a MongoDB competitor? maybe?
        
         | ovaistariq wrote:
         | Thanks for the feedback on the doc.
         | 
         | At the core of it, it is a transactional document database that
         | uses FoundationDB under the hood for data persistence. It
         | automatically provides search capability on the data stored
         | (similar to Elasticsearch) without you having to pipe data to
         | Elasticsearch. Then there is event streaming capability that is
         | also provided out-of-the box, so you can use simple
         | publish/subscribe APIs to build event-driven applications
         | without having to introduce Kafka.
         | 
         | A better comparison would be against MongoDB Atlas. Here are
         | some of the ways it is differentiated from Atlas: - Open source
         | that you can deploy anywhere, the only requirement being
         | Kubernetes. Whether it is your cloud environment or on-prem, it
         | doesn't matter. - Much simpler API interface as compared to
         | MongoDB with native support for HTTP enabling it to be used
         | from anywhere where HTTP is accessible - edge, mobile, etc. -
         | Built with strong transactional consistency guarantee (strict
         | serializability) - this is the benefit of using FoundationDB
         | for data persistence. - MongoDB Atlas is based on 10 years old
         | architecture and the industry has evolved quite a bit thanks to
         | the cloud. Tigris has a micro-service based architecture with
         | separately deployed components (compute, storage, indexing)
         | that can each be scaled independently. - True serverless
         | experience, which is of course possible through a modern
         | architecture. - Automatic indexing, so you don't spend time
         | optimizing queries and secondary indexes.
        
       | throwaway2016a wrote:
       | So where does the data actually live? I read through the page and
       | I'm still not clear.
       | 
       | Is Tigris itself a database? Specifically it seems, a multi-
       | paradigm database? And if it is, what is it that makes it a
       | platform and not simply a database?
       | 
       | Not criticizing, these are just questions I have initially trying
       | to grok it at a quick glance.
        
         | ovaistariq wrote:
         | We use FoundationDB's transactional key-value interface as the
         | underlying storage engine. This provides us with a low level
         | building block that can scale to peta bytes of data.
         | 
         | The reason it is more than a database is because it provides
         | more than the structured data storage that is provided by
         | databases.
         | 
         | At the core of Tigris is a transactional document database
         | built on FoundationDB. Then Tigris automatically indexes the
         | data so you can run search queries (think Elasticsearch)
         | without having to pipe the data to Elasticsearch. Tigris also
         | provides an integrated event streaming system so that you can
         | build event-driven applications (think Kafka, Google PubSub,
         | etc). The beauty of the event streaming system is that you can
         | then also run search and read queries on the events data
         | automatically.
         | 
         | We have explained the high level architecture here:
         | https://docs.tigrisdata.com/overview/architecture
        
           | throwaway2016a wrote:
           | Thank you for the link. That is helpful.
        
       | asdfasdfsdf1231 wrote:
       | it's a REST+json payload frontend for foundationDB.
       | 
       | ...by people who doesn't feel that the underlying tech is
       | important to mention. So, not for this crowd.
        
         | ovaistariq wrote:
         | The REST+json part is one part of it. FoundationDB is an
         | awesome tech and proven at scale. But it only provides a simple
         | key-value interface.
         | 
         | But we have built multiple features on top of it to enable it
         | to be used as complete platform. Query processing layer that
         | can do complex read queries similar to FoundationDB. Ability to
         | do full-text searches similar to Elastisearch. Ability to use
         | it for event streaming through simple and easy to use
         | publish/subscribe APIs without the complexity of Kafka.
         | 
         | All of it is done in a cohesive manner, so for example, when
         | you use it as your event streaming system, you get out of the
         | box capability to query and search data without having to pipe
         | the data somewhere else.
        
       | dang wrote:
       | This looks like a great project but it's not a valid Show HN if
       | people can't try it out. Please see
       | https://news.ycombinator.com/showhn.html. Note the bit about
       | signup pages.
       | 
       | (I've taken Show HN out of the title now.)
        
         | ovaistariq wrote:
         | People can try it out in local development environment:
         | https://docs.tigrisdata.com/quickstart
         | 
         | Besides that, it is Apache2 license which means folks can
         | deploy it to their k8s and run it.
        
           | dang wrote:
           | Ok! I'll put Show HN back in the title. Sorry for
           | misunderstanding.
        
       ___________________________________________________________________
       (page generated 2022-09-20 23:01 UTC)