Launch HN: Outerbase (YC W23) – A new UI and editor for your database
38 by burcs | 16 comments on Hacker News.
Hi HN – we are Brandon and Brayden (confusing we know), and we are building Outerbase ( https://ift.tt/ebQ8DoB ) a better interface for your databases. Think Google Sheets or Airtable, but on your relational database. We provide a collaborative UI on top of Postgres, MySQL and other databases, enabling teams to view, edit and visualize their data. Here’s our short demo video: https://www.youtube.com/watch?v=38RslBYdZnk Accessing data is a challenge to team members who aren’t data analysts or engineers. Databases are usually locked down to a few team members, and everybody else has to rely on them to get access. Most non-engineers can’t (and don't want to) use developer tools, and developers don't want to write SQL for teammates all day. Technical employees end up being bottlenecks for access to data. In some cases this can be extreme—we’ve seen publicly traded companies with only 2 data scientists for the whole org! Our goal is to make data accessible to everyone who needs it. We have an intuitive spreadsheet-like editor that sits on top of your databases, as well as the capability to save and share queries. You can take those queries to create charts and dashboards for your team. You can also query your data using EZQL, our natural-language-to-SQL conversion. We use OpenAI to power the natural language process, and we pass the relational schema on top so we can easily know the relationships between your tables. Prior to starting Outerbase, I (Brandon) was a product designer at DigitalOcean and noticed that while DO did a good job making it simple to create databases, there wasn't a modern solution to manage them afterwards. Often users had to use PHPMyAdmin, psql, or $insertDBGUIHere, and to be honest most of them do not provide the best user experience. They’re for a very technical audience, and fall short of making data accessible for everyone. We saw a need to do for data what DigitalOcean did with the droplet. Brayden led an engineering team at Walmart and dealt with data at a completely different scale. He led the iOS, Android, and web teams for their amends experience and a lot of time was spent pulling, querying, and generating reports on that data. So when we talked about building this he was immediately in. How it works: We have a React-based frontend that uses a combination of Sequelize and some native libraries to normalize the underlying SQL, which allows us to query and connect to different relational databases. Currently we support Postgres, MySQL, Snowflake, BigQuery, and Redshift. We don't store any of your end data—everything else is encrypted and all credentials are stored in KMS. Tools like Outerbase make it possible for people to do their jobs more directly. One of our larger customers uses us as a way to moderate what gets posted to their app. Users submit data and our customer will actually go in and mark a column approved if the content is ok for their audience. Outerbase is available to use today. You can try it for free with 1 user and then if you want to collaborate or use additional features you can upgrade to our pro tier or the obligatory “call us” enterprise tier. We would love to hear your thoughts on the product, you can sign up today for free, use the sandbox database or connect your own! We know the space isn’t exactly uncrowded, but we hope our approach to building something that is intuitive and collaborative will make it easier for everyone to access their data. We know some HN users are not our target audience because they’re technical and already have tools they’re comfortable with—but even then you might want a tool so your team doesn’t have to bug you as much with data requests! We let you simply give them read access to their db and enable them to do their own queries. We’d love to hear your views, opinions, experiences about this. What would you want to see from a database/data visualization tool? Looking forward to discussion in the comments!
Thursday, March 16, 2023
Wednesday, March 15, 2023
New top story on Hacker News: Show HN: Ingest data from your customers (Prequel YC W21)
Show HN: Ingest data from your customers (Prequel YC W21)
22 by ctc24 | 1 comments on Hacker News.
Hey HN! Charles here from Prequel (https://prequel.co). We just launched the ability for companies to import data from their customer’s data warehouse or database, and we wanted to share a little bit more about it with the community. If you just want to see how it works, here’s a demo of the product that Conor recorded: https://ift.tt/I7uDxmG. Quick background on us: we help companies integrate with their customer’s data warehouse or database. We’ve been busy helping companies export data to their customers – we’re currently syncing over 40bn rows per month on behalf of companies. But folks kept on asking us if we could help them import data from their customers too. They wanted the ability to offer a 1st-party reverse ETL to their customers, similar to the 1st-party ETL capability we already helped them offer. So we built that product, and here we are. Why would people want to import data? There are actually plenty of use-cases here. Imagine a usage-based billing company that needs to get a daily pull from its customers of all the billing events that happened, so that they can generate relevant invoices. Or a fraud detection company who needs to get the latest transaction data from its customers so it can appropriately mark fraudulent ones. There’s no great way to import customer data currently. Typically, people solve this one of two ways today. One is they import data via CSV. This works well enough, but it requires ongoing work on the part of the customer: they need to put a CSV together, and upload it to the right place on a daily/weekly/monthly basis. This is painful and time-consuming, especially for data that needs to be continuously imported. Another one is companies make the customer write custom code to feed data to their API. This requires the customer to do a bunch of solutions engineering work just to get started using the product – which is a suboptimal onboarding experience. So instead, we let the customer connect their database or data warehouse and we pull data directly from there, on an ongoing basis. They select which tables to import (and potentially map some columns to required fields), and that’s it. The setup only takes 5 minutes, and requires no ongoing work. We feel like that’s the kind of experience every company should provide when onboarding a new customer. Importing all this data continuously is non-trivial, but thankfully we can actually reuse 95% of the infrastructure we built for data exports. It turns out our core transfer logic remains pretty much exactly the same, and all we had to do was ship new CRUD endpoints in our API layer to let users configure their source/destination. As a brief reminder about our stack, we run a GoLang backend and Typescript/React frontend on k8s. In terms of technical design, the most challenging decisions we have to make are around making database’s type-systems play nicely with each other (kind of an evergreen problem really). For imports, we allow the data recipient to specify whether they want to receive this data as JSON blob, or as a nicely typed table. If they choose the latter, they specify exactly which columns they’re expecting, as well as what type guarantees those should uphold. We’re also working on the ability to feed that data directly into an API endpoint, and adding post-ingestion validation logic. We’ve mentioned this before but it bears worth repeating. We know that security and privacy are paramount here. We're SOC 2 Type II certified, and we go through annual white-box pentests to make sure that all our code is up to snuff. We never store any of the data anywhere on our servers. Finally, we offer on-prem deployments, so data never even has to touch our servers if our customers don't want it to. We’re really stoked to be sharing this with the community. We’ll be hanging out here for most of the day, but you can also reach us at hn (at) prequel.co if you have any questions!
22 by ctc24 | 1 comments on Hacker News.
Hey HN! Charles here from Prequel (https://prequel.co). We just launched the ability for companies to import data from their customer’s data warehouse or database, and we wanted to share a little bit more about it with the community. If you just want to see how it works, here’s a demo of the product that Conor recorded: https://ift.tt/I7uDxmG. Quick background on us: we help companies integrate with their customer’s data warehouse or database. We’ve been busy helping companies export data to their customers – we’re currently syncing over 40bn rows per month on behalf of companies. But folks kept on asking us if we could help them import data from their customers too. They wanted the ability to offer a 1st-party reverse ETL to their customers, similar to the 1st-party ETL capability we already helped them offer. So we built that product, and here we are. Why would people want to import data? There are actually plenty of use-cases here. Imagine a usage-based billing company that needs to get a daily pull from its customers of all the billing events that happened, so that they can generate relevant invoices. Or a fraud detection company who needs to get the latest transaction data from its customers so it can appropriately mark fraudulent ones. There’s no great way to import customer data currently. Typically, people solve this one of two ways today. One is they import data via CSV. This works well enough, but it requires ongoing work on the part of the customer: they need to put a CSV together, and upload it to the right place on a daily/weekly/monthly basis. This is painful and time-consuming, especially for data that needs to be continuously imported. Another one is companies make the customer write custom code to feed data to their API. This requires the customer to do a bunch of solutions engineering work just to get started using the product – which is a suboptimal onboarding experience. So instead, we let the customer connect their database or data warehouse and we pull data directly from there, on an ongoing basis. They select which tables to import (and potentially map some columns to required fields), and that’s it. The setup only takes 5 minutes, and requires no ongoing work. We feel like that’s the kind of experience every company should provide when onboarding a new customer. Importing all this data continuously is non-trivial, but thankfully we can actually reuse 95% of the infrastructure we built for data exports. It turns out our core transfer logic remains pretty much exactly the same, and all we had to do was ship new CRUD endpoints in our API layer to let users configure their source/destination. As a brief reminder about our stack, we run a GoLang backend and Typescript/React frontend on k8s. In terms of technical design, the most challenging decisions we have to make are around making database’s type-systems play nicely with each other (kind of an evergreen problem really). For imports, we allow the data recipient to specify whether they want to receive this data as JSON blob, or as a nicely typed table. If they choose the latter, they specify exactly which columns they’re expecting, as well as what type guarantees those should uphold. We’re also working on the ability to feed that data directly into an API endpoint, and adding post-ingestion validation logic. We’ve mentioned this before but it bears worth repeating. We know that security and privacy are paramount here. We're SOC 2 Type II certified, and we go through annual white-box pentests to make sure that all our code is up to snuff. We never store any of the data anywhere on our servers. Finally, we offer on-prem deployments, so data never even has to touch our servers if our customers don't want it to. We’re really stoked to be sharing this with the community. We’ll be hanging out here for most of the day, but you can also reach us at hn (at) prequel.co if you have any questions!