When I worked in AWS S3, I spent a lot of time in Excel. Even as a dev, it was the fastest way to explore data, build models, and share forecasts with business partners. My Excel usage was plagued by slow performance, poor cloud integration, and no first-class Python support. I loved the richness and responsiveness of Excel, but I had to give up too much power to get it. This felt like a false choice, so 3 years ago I started working on it.
Today we're launching Row Zero. Row Zero looks and feels like Excel and Google Sheets, but 100-1000x faster. You can easily import gigabytes of CSV, JSONL, and Parquet files or connect directly to Snowflake, Redshift, Postgres, and S3. We also support Python natively. You can call Python functions that return pandas data frames and manipulate the results directly in the spreadsheet.
Under the hood, Row Zero is a high-performance columnar engine written in Rust. Running in AWS lets us scale compute up and down and import quickly from S3 and Snowflake. When you open a workbook, we place it in the AWS region closest to you so it feels as snappy as a desktop application.
The app is built by 5 ex-principal engineers from Amazon S3, Tableau, and Airtable. We're the team that wrote the file system that powers S3.
We've been in beta for a year. Use us to refine big CSVs, build complex financial models, create dashboards, and share large data sets. We're also a killer Snowflake/Postgres client. Give us a try and let us know what you think.
It varies depending on what you are doing, but is probably 100x faster on average.
Some things are literally 10000x faster because we are internally using algorithms with better asymptotic complexity than Excel, but there are a few edge cases where we are maybe only 10x faster
(but we are always working to improve that — half my job is just analyzing flame graphs and grinding out perf improvements)
When we claim 100x faster than desktop Excel, we're looking at supported row counts, import speeds from Snowflake, and time to drag large XLOOKUPs. We'll do a deep dive on performance in another blog post next week. Stay tuned!
All our backend engineers were on the S3 filesystem team.
I'm Grant Slatton, founding engineer at Row Zero, and before this I designed and led the team that built S3's new filesystem, ShardStore (check out this paper https://www.cs.utexas.edu/~bornholt/papers/shardstore-sosp21...). Our other Row Zero backend engineers (Breck, Erich, Greg) were all on the team.
Please, please, please put an “about us” page on your site. People get leery when there aren’t named humans identified as being behind a product that’s asking for production data access.
VCs invest in people and not products/ideas from what I have heard/read. I think it is imp. to mention that you were on the S3 team if you are building something like this. Huge credibility factor.
We haven't benchmarked against gnumeric, but will make a perf blog post in the next week or two (will post on HN too) and will see if we can add it to the comparison mix
What I'd love to see is an easy workflow to make this supplant Google docs. Right now, let's say i want a shared spreadsheet. I need to:
1) Signup for an account
2) Create a workbook
3) Click share and put in friend's email
4) They get an invite
5) Now they need to sign up
6) They can edit my doc
I'm not a paying customer (or even a user... I just heard of this), so take this with a grain of salt, but what I'd love to see is a super-friction-less way for me to share a doc and make it editable without others needing accounts. Cut out as many steps as possible above. Doing this can be a great tool for marketing... what's better marketing than easily collaborating on a spreadsheet on a site that my friend is already using and that already looks very similar to tools I'm familiar with?
This feature would be the fastest way for the company to have the least number of paying users. As a user, I'd pay for one account and then share new spreadsheets with anyone who asks for one on the Internet.
If I’m the type of user who would ever consider paying, I’m most definitely not the type of person who wants to ask a stranger on the internet to setup a new spreadsheet for me every time I want to use one. I wouldn’t even want to ask a friend or coworker.
Fortunately the Internet is real big, so there's definitely going to be a discord or subreddit or private slack where one person has a paid account and just makes new sheets for other people. it doesn't really scale though and it's cheap enough that most people will just make their own instead of being reliant on someone. broke teenagers isn't a market you have to fully satisfy.
Starting from a place of "I want to start providing this to my employees yesterday"...
I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it.
For example, the docs show the product wants static creds for a Postgres database or signed URL for S3 bucket instead of leveraging best-practice service-to-service identity and access management.
Maybe you support what I want, and I didn't find it at first glance.
This either ...
(a) needs to support modern dynamic or token-based authentication (e.g. Oauth2.0 client credentials grant, JWT, or for enterprises ideally CSP native IAM in Azure/GCP/AWS such as share S3 by cross account bucket permissions policy instead of signed URL, etc.), or ...
(b) allow firms to operate this themselves so the spreadsheet is run in the firm's security context, no creds are shared and data never leaves.
As you are running in AWS, providing this to run in AWS IAM context could solve it, but it's likely worth your time collaborating closely with FS firms that have solved cloud-native infosec at scale for the world's most demanding regulatory environments such as GSIFIs/GSIBs, since if you can do that, it's secure for anyone. Similar for HIPAA or FedRAMP.
If your customers can be fully best practice compliant within these regulatory regimes without having to lower their standards or get exceptions to use you, then it's above the bar for pretty much everyone.
// Full disclosure: Although using all 3 of AWS, Azure, and GCP, I was an AWS CAB member for half a decade (as principal engineers you likely know what this means), with a native-AWS preference.
For S3 specifically, we support IAM-based role assumption. If you go to Data > Import from Amazon S3 > Add S3 Bucket, you can grant our AWS account permissions to read an S3 bucket in your account.
We also have dedicated hosting options for our Enterprise tier.
If there's a specific data source you'd like us to support OAuth integration for, let me know, and we'll add it.
> you can grant our AWS account permissions to read an S3 bucket in your account.
That seems like a huge privacy hole. It sounds like you're offering spreadsheet-as-a-service, where you scale up AWS spot instances based on query size.
This means, if you are served a national security letter with a gag order saying to turn over my data without telling me, can you?
If you are not NSL proof, are you able to demonstrate who from your firm can, and cannot, by technical guarantee not by policy in the “signed agreement” sense, see my data, and can I see in an audit log any time and every time any of those people do see my data?
On the contrary, that scenario (as well as, "what if your SaaS provider or CSP is hostile?"), are great "clarifying" questions to understand the security architecture of a product that is very likely to see some incredibly sensitive data.
It is possible for the answer to be that a service is NSL proof -- with asterisks, and the asterisks are very interesting to discuss.
And no, it's not about the US security apparatus for most firms, although if you take a look at AWS's security teams, you'll see there is a lot of experience exchanged, and AWS does secure the US security apparatus' data.
XLSX is an open format, why invent another? xkcd 927
python in the app needs to be wholly self contained so whatever the backend it uses, it's separate from anything else on the system.
charge through the nose for desktop clients because of how much it costs in development and support time. people who want native clients so it's not up on a cloud somewhere for whatever reason can pay for that privilege.
I live in excel in a multibillion dollar company as the "excel" guru... though my company doesn't really have big data generally speaking
I would love a performant desktop excel replacement - I miss using excel 2003 - it has been downhill ever since...
That said, I'm clearly not the target market for this product though I believe there's some degree of frustration with how poorly modern excel works with many files now which this product may address.
I would guess that making this a light-weight and performant (not electron) desktop app (ideally portable so installing it wouldn't require admin access) with substantial feature parity and compatibility with excel would be a big deal - I'd install it right away...
This looks like something that I could use right away, but I wonder, since we can write Python, does this mean that we can write back to one of the native backends (e.g. Postgres)?
Currently, the only way to do this from Excel (e.g. saving a snapshot of an analyst's current dashboard that they just built) is through a macro, which then starts the (understandable) descent into Excel's External Content and Trust Center permissions hell.
You can technically use the Python to write back to Postgres if you are comfortable putting your creds into the code window. The downside of this is your creds would be viewable to anyone you share the workbook with.
We have gotten a lot of requests for write-back-to-DB (Snowflake, Postgres, etc) so will be adding first-class support for this feature soon that will use the same connection creds which are stored encrypted in KMS and are not viewable to people you share the workbook with.
Would love to chat about your use-case if you want to reach out to us at contact[at]rowzero.io
Nothing in particular. I'd have been happy with anything that has a real open source community around it, which VBA doesn't. For data tasks, Python's a natural choice. We've also had requests for R, which is on our roadmap.
The power of excel is that everyone has it and most people have a ton of familiarity with it and there’s a million results for anything you search Google that you don’t know how to do. Basically, all the network effects, bec you’re right if excel were a new product today it would lose to every single competitor that does it much better.
You'll also need formatting to be the same to get adoption. e.g. I wanted to format numbers as currency, and got USD$x,xxx as a result, and no obvious way to change that to $x,xxx.
I’m in New Zealand if that helps. Generally (please) don’t assume location dictates formatting, while Excel’s assumptions are often incorrect and so custom formatting is a requirement.
Datafusion, Polars, and us are all based on Arrow. Datafusion is more targeting database users, Polars is targeting Python programmers/dataframe users, and we are targeting spreadsheet users.
They are all ultimately just different UIs on top of Arrow.
They're complimentary tools. We can take data out of the spreadsheet and put it into Polars instantly (you can do this in the Python code window if you want), etc.
Regarding why not implement our spreadsheet built on top of those: spreadsheet allow for heterogenous types in columns, so that requires a lot of extra infrastructure to manage, whereas Datafusion and Polars require homogenous column types.
Equals and Row Zero are in the same space. They've put more effort into their suite of cloud data connectors, while we've focused on performance and first class Python support. We'll be adding more connectors in the coming months.
Excited to see this. I built quite a few data-rich projects / dashboards with gSheets as backend/api - or as input UI, fetched to SQLite.
I'd be looking very much forward for: data validation, conditional formatting (including heatmaps) and - what gSheet doesn't offer natively, multiple choices cells via data validation or values from another column/sheet.
<s>I was surprised I couldn't way to view a spreadsheet as a DataTable, or back as a DataTable</s> (LE: found later how in documentation). And no sticky/frozen header row, ugh.
Cherry on top would be gSheets like SQL flavoured QUERY.
LE2: to add the wishlist, a potentially killer feature to/for some, dashboard type of sheet, with minimal/layout options –rows & columns blocks that can host charts & text (headings & paragraphs), with global filters – it would add a feature or two complementary to what gSheets offers.
And at some point maybe, comments - per sheet or column only.
If you're open to it, email us at contact[at]rowzero.io and we would love to do a call to talk about your use case, what features you want, etc. We love doing customer calls and adding delightful features.
Tell us about the stack you're using to build this. Also the biggest tech challenges you've faced and solved? But most importantly, does your family still use Google Spreadsheets?
Google Sheets is banned in our households, we planned our neighborhood block party in Row Zero!
Tech stack:
Everything runs on AWS
Frontend: TypeScript + some Rust compiled to WASM, our own virtualized custom canvas magic
Backend: Rust, Apache Arrow
The biggest tech challenges... where to start.
1. As with any editor application, Undo/Redo is devilishly hard
2. A spreadsheet is modeled as a Directed Acyclic Graph where cells depend on other cells down to some root cells. There are a TON of fascinating graph theory algorithms you can bring to bear here. Some of the hardest problems I have ever worked on. My whiteboard looks like an insane person's with crazy arrows between cells and stuff.
3. Sometimes there really is no magic bullet and you just have to run benchmark, get flamegraph, chip away 3%, repeat, do that 100 times and you are very fast. Gotta grind.
We were fortunate to work in AWS which has some of the gnarliest datastructures and algorithms problems in the world, so we got really good there. Spreadsheets are really just more datastructures and algorithms on the backend.
Our frontend guy is brilliant and built a lot of awesome stuff at Airtable, but I can't speak to the craziness that is high-complexity high-performance frontend. But it's absolutely necessary to a good product too!
I don't have any great book recommendations because I learned on the job mostly.
For a project that will teach you literally everything there is to know about backend development:
1. Write a simple PUT/GET/DELETE REST API network layer, this should be a few hundred lines of code max depending on how much you choose to lean on libraries vs write it yourself
2. Then, write a simple in-memory blob store behind the PUT/GET/DELETE REST API. Just use a very simple hashmap of keys to data. You now have an in-memory S3 mock!
3. Now, rather than in-memory hashmap, start saving the files to disk. Write code that allows you to start and stop the process and recover all the data from disk. Now you have a persistent S3 mock.
4. Now, start finding the limits of this application. Write a program that calls your API with different usage patterns to load test it. Find the limits.
5. Now start optimizing. You can go as far as you want here. This optimization process was my whole career at AWS S3, and most of it at Row Zero.
6. If you want to really learn some advanced data structures and algorithms, stop using the filesystem directly, and write your own storage mechanism. Allocate 1 giant 16GB (or however large) file and store all of your blob data inside that 16GB "partition". You have to do all the serialization and retrieval etc yourself.
Your filesystem is already doing this for you when you store as files (look up how the ext4 filesystem works, inodes, pages, etc). But your filesystem is probably optimized for consumer use, not this blob-storage system use.
So you can implement your own much faster version if you want. If you want to really learn datastructures and algorithms, try to code a simple Log Structured Merge Tree. This will teach hashes, trees, bloom filters, serialization, deserialization, etc, all with high performance in mind.
Nice work, did you start off by looking at any previously built canvas-like spreadsheets or was it straight to "virtualized custom canvas magic"?
I interviewed at a spreadsheet company (for a frontend role) and they asked, "how would you go about determining what cells need a border when a user clicks an individual cell, clicks a cell and selects multiple cells, clicks a cell next to an already selected cell." Fascinating problem and we talked about solutions for a little bit.
Noticed that you can't unselect a cell once it's selected? I'm on a Mac with Chrome (latest, no updates available).
Repo steps:
1. Select a few cells (⌘ + click) or an individual cell
2. Try unselecting (⌘ + click) those same cells clicked in #1
3. Cell is not unselected
Row Zero frontend dev here -- when architecting, we looked at some off-the-shelf canvas-based table tools, but ultimately rolled our engine for more control & flexibility with our growing feature set. We elected for canvas over DOM for perf among other reasons (eg DOM scrollbar virtualization is hard when MAX_ROW * ROW_HEIGHT exceeds the maximum allowed browser element height).
Great interview question. Tons of nuance to drawing borders on adjacent cells, how to handle varying thickness, etc. Once you start looking closely, you notice the pixel differences between how this gets handled by various spreadsheeting tools.
Thanks for the report! This one's already on my list actually (selection negation & unique selection deduping) -- look for a fix soon.
I don't remember looking at Glide, although it looks really nice & full-featured. I'll have to play around with it sometime. I do remember trying out https://www.npmjs.com/package/@deephaven/grid.
One pivotal feature that is difficult to map onto 3P tools is our data table UI, which is a separate scrollable grid that floats on top of the main sheet. That, combined with the complexity of formula selection, inserting buttons into cells (header dropdowns, filter, sort), led us to decide that rolling our own solution for full control was the right choice.
Congrats on releasing the product! What are you using instead of the native scroll event of a browser element? Are you listener to `onwheel` events? Have you find a way to keep scrolling momentun scroll-browser/cross-device or do you normalize the delta to +1/-1?
I am the creator of DataGridXL (https://datagridxl.com), an Excel-like data grid component and it uses native scrolling. However, the document/sheet height/width is indeed limited by max div dimensions. Does your spreadsheet have a max?
What made you choose this tech stack? I'm especially wondering about Rust, was that something you had familiarity with before so just went with that? Did you evaluate a few different options and decided that would best fit this use-case?
(I have very minimal familiarity with Rust, I'm just wondering here.)
I was especially excited to learn that RZ is built on Apache Arrow internally, which makes it easy to integrate with other Arrow-based applications and the emerging "Composable Data Stack". Really exciting stuff, they're just getting started!
This looks really promising, and I love that you make a demo available with no account. But I don't have time to track down some sample data to test it with.
I'm guessing this post is going to the front of HN. If you've got some sample data, you should put it into the demo sheet ASAP. Or at the very least, provide some links to s3 files the user can manually add to test it themselves.
This looks really promising. We generate about 1gb of financial CSV files per day for finance/accounting/audit teams and the number one response is "wow this data is great, but my computer just can't handle it".
The biggest issue that I think I would run into in my organization is that all of the spreadsheet lovers are Excel die-hards and they refuse to even use Google Sheets, not to mention something else that isn't Excel.
But maybe they could finally be convinced to stop complaining aboutrequesting huge files with something like this...
We try really hard to be Excel-compatible with all our formulas and hotkeys, etc. If there is a formula or hotkey we are missing, let us know and we will add it (usually with < 24 hour turnaround time!)
The use-case you describe is exactly what we built it for. There are a lot of people who have data that is no longer human-scale and won't fit into Excel, but they still want to use their Excel skills.
We love Excel and spreadsheets, but when working at AWS we found we just had too much data to fit into it.
Its Martin Skreli (yes that one) -- but see how fast this guy is with excel... this is what I imagine when I think of excel power users...
(But also, he does a lesson in DD on investing and doing calcs in Excel - so aside from awesome Excel input, there is good investing info here - recall this was the guy that bought a medical company and immediately raised the price 7,000% or some such (he then bought the Wu Tang Album whilst imprisoned)
I've found that while people don't want to change out of Excel they are forced to by the size of new files. The more data is generated by computers, the less likely it is to fit in Excel
I imagine many professions won't be able to use Excel in 10 years based on this trend.
I'm curious, which ones of these limits are you hitting? https://support.microsoft.com/en-gb/office/power-query-speci... If your answer is "Maximum number of rows filled to worksheet", you should understand that this means exactly what's written, rows filled to the worksheet - you can still have more rows in the source and do your transform/queries on that.
omg dude - shouldn't these users be querying a database in some capacity where this data resides in the first place?
perhaps via some more "accountant friendly" app than SQL?
That said, I suppose that's partly the goal of this product... a visual/faster alternative to SQL though I personally avoid putting big data in excel, I just (as an accountant myself) carve out subsets from SQL and then peruse it via excel to identify whatever transactions/activity I need to analyze since the web interface for the ERP is such slow steaming garbage...
I'm more in search of a better excel than an excel which can handle big data as I suspect many users will somehow, no matter how well this is built, make it slow/terrible whereas an SQL based approach could be multiple of orders of magnitude faster....
Honestly, I'm really excited about this next generation of spreadsheet software.
- Causal.app
- Rows.com
- Equals.com
- and at least 50 others I've found
I'm waiting for someone to create a really high performant spreadsheet engine that runs in WASM to power even more spreadsheet-y applications. The direct manipulation of spreadsheets is super underrated.
Row Zero supports Python pandas, which handles multi-dimensional data. So you can process your data with Pandas in the code window and then view "2d slices" of that data in the spreadsheet UI. Feel free to message me at breck at rowzero.io if you'd like to do a session together to get you started.
Excel online still struggles to work with databases well. In classic disruption theory (the real theory by Clayton, not the TechCrunch 'disruption'), these products have less features but are simpler and can win the low-end of the market then move up-market over time.
I suspect that people glued to M365 ecosystem are the LAST ones to consider leaving Excel online, but that's okay!
https://spreadsheets-are-all-you-need.ai/ has a 1.5G (in excel-binary save form) spreadsheet that would make an entertaining benchmark (not a particularly relevant one for your target market, unless you want to get into "frightening educational tools for AI researchers" which is not a notably excel-friendly space - just a hilarious one.)
I have a demo I will post soon that runs MNIST in Row Zero, we should be able to handle all of GPT2 without too much trouble, probably a lot faster than Excel, we may have to try it!
I will post it next week! It's very fun to play with. Also a good demo of Row Zero's templating capability — I can make a template so when you click the link, you get your own copy you can mutate and play with.
I'm a bit obsessed about spreadsheets and as someone who's building something similar (but not identical), it feels great to see all these next-gen spreadsheets on HN.
Spreadsheets are hard to do and even harder to do right, so congrats on launching—although given your backgrounds I don't think you ever lacked the manpower to let this be a technical challenge ;-)
My initial reaction:
* It does feel pretty fast
* but spreadsheets on the browser always represent an inferior UX
* the data tables / formula tables are a solid idea
* no self-hosting outside of Enterprise makes switching to this harder than it ought to be
* limiting the free plan to 3 sheets feels like a strange decision
Inferior to a native app. Navigating it with the keyboard is clunky, the UI is never as crisp and responsive, it's harder to save and open files... the list goes on
Is it true? Google sheets is great, google docs is great, and hyperlinks! How much native app fast UX is due to using local state on disk? The future is not on local disk!
Google has the benefit of having all of Google drive around it
But even then, the benchmark is Excel. Nearly every Excel user is saving files to disk. Companies like to own data in a shared drive on a network. Maybe making networked drives better is another problem that needs solving, but I don't think spreadsheet applications should disregard that and just hope everyone moves to online. At a minimum you should give users a choice (which Excel/Office does, by the way)
And we still haven't talked about navigating the UI with the keyboard. Limiting power users to online-only is like telling vim users they have to use Notepad++. Sure, they can do everything they could in vim, but it's overall objectively worse
Ok, you're right – i don't think a smooth transition is possible in the office market – but I also don't think you can disrupt Office from within. Example: the thing that disrupted the New York Times was not a better newspaper, rather Facebook
I agree! Which is why I'm not building the next Excel, but rather something different which offers (or "will offer") ~feature parity with Excel spreadsheets but approaches knowledge work and document authoring from an entirely new angle
The benefit of files is that they are a consistent, application-independent abstraction. You can copy, move, rename, backup, version, and generally organize them however you want, restrict or grant access, without being constrained by what the respective application supports. Importantly, you can organize files from different applications together without those applications having to know anything about each other. Hyperlinks are no substitute for the object-like, independent nature of files.
Applications that are not based on files create their own little separate universe, or rather island, that isn’t really interoperable.
> files are consistent and application-independent
I see diverse, inhomogenous state schemas that are deeply coupled to the originating application (internal data structures serialized to disk!) and have arbitrary legacy structural constraints ("document") as well as seams between application silos
I sense a trap, but i'll bite – APIs and schemas and other logical data models can be remixed, at least in principle. Physical data models (i.e. coupled to storage layout) are too low level to be useful, all you can do is load them back into into their originating app.
That's certainly true among a subset of users who demand Excel power features, but it is not a universal benchmark. People who more highly value collaboration might prefer Google Sheets. There are tons of users and use cases where the choice of local storage is irrelevant or even a drawback.
Microsoft teams has the option to open all shared files in the browser so you can have multiple "teams" Microsoft files open at once. This is the direction spreadsheets are going.
I agree it feels clunky to me who grew up on excel the application. I memorized a few dozen keyboard shortcuts that are all broken in the "teams collaboration browser spreadsheet" sigh.
In Teams you can not work on a Excel Sheet shared in a chat. You have to share it in a Team .. you have to ask the IT to create a Team for you first .. great.
Indeed. In addition to the UI issues, there's no way this product can be "the fastest spreadsheet" when it's browser-based. By definition it runs at least ten times slower than native apps will.
For certain apps, it feels much more comfortably mentally compartmentalized when that focus is not in browser... (this is just my opinion), but I find that I typically have so many tabs open - I like to have certain things on not my browser (at times a tab can crash the whole browser)
Attempting to import from various sources (urls and upload) and it fails:
We wrote our own CSV parser to get fast import performance, and we do occasionally encounter novel encodings and weirdness. I sent you an e-mail to get more details.
At the time of this comment (edit: since this comment, they addressed this, check the replies), on your pricing page you have "SOC 2 Type II Security Compliance" not being checked off on the free tier but it's checked in the others. The same thing applies to "HIPAA Compliant and BAA" except this isn't enabled for free and pro plans.
What makes the free tier different here? Are you storing free data in a different area with many less restrictions on who has access to it? How do I know what I upload is safe from being analyzed or sold? Are you using this data to train any data models but only in the free / pro tiers that aren't SOC 2 or HIPAA compliant?
IME working at SaaS providers in my past, there's no practical difference in the underlying implementation; it's market segmentation. It's a great way to help SaaS providers attract more revenue. Customers who care about these compliance regimes are the target cohort and are more likely to pay for the ticked box.
There's no difference in how data is stored or processed between the tiers. We updated our pricing page to address the confusion. We only provide the SOC 2 report or BAA for Business accounts.
Generally: the free tier won't get you the documentation --- to get the SOC2 report or the BAA, you need a paid plan. Which makes sense as a segmentation strategy. Especially in the case of SOC2, where providers really should charge for that report.
As someone who used to work on Excel, awesome work and congrats on the launch! I get that it's easy to bash on VBA, but I'd argue it's what made Excel what it is today (though maybe not the language/runtime per se, but rather the ergonomics).
I feel pretty confident saying that probably 5% of the world's economy runs on VBA macros that were started by some eager worker that was tired of doing repetitive tasks and wondered what that "Record Macro" button did. I've heard that same story personally from so many users, about how they learned to code by hitting "Record Macro", doing something and looking at the resulting code. Their macro then grows and grows and ends up powering the entire business, but becomes an unmaintainable mess.
If you add the ability to record macros and maybe a VBA -> Python cross compiler, that would probably be killer for a lot of people. Though honestly, I've seen some stuff in VBA that's probably best left alone (e.g.: a self-rewriting VBA macro).
That being said, I'm sure your biggest hurdles are going to be cultural rather than technical. Excel is just so ingrained in so many business. But I genuinely wish you best of luck and am rooting for y'all!
From what I remember (that was almost almost 10 years ago, so a bit foggy now), it was some finance/trading people (the crazier stuff is always from finance people) that were doing some optimization work and found they had better performance by putting back the values in the macro itself and rerunning it. Something to that effect. (Or was it for versioning? I forgot the details honestly)
I think they were using file system calls with some tools to rewrite the file directly. But IIRC it's possible to do it just via the API.
1) The lack of a migration path from workgroup (LAN) to client-server for Access et al. So dumb. SQL Server should have become a first class citizen of Access. Or Access become a viable front-end end to SQL Server. Where swapping JET and MSSQL was a drop-in no-brainer. (Maybe that happened later...)
2) Not unifying tabular data. And then make Excel and Access "modalities" (?) for accessing that data. Lotus' Symphony (successor to 1-2-3) was so awesome; hybrid database and spreadsheet. aka The Correct Answer™. And Symphony was on DOS! (Lotus' Improv was even cooler. I wish I knew why it didn't succeed.)
I guess all this ML data pipeline Parquet NumPy stuff finally separated tabular data from how it's used. Yay.
I haven't used the Microsoft stack in anger since late '90s, when Java emerged, so maybe the .Net/CLR reboot mooted my complaints.
I never had the chance to use Borland's tools (Paradox, QuattroPro) in anger, so don't know if they did any better.
One of my previous work places with an auditing data set company.
We'd collect data sets from various sources (like public filings from the SEC) and the we'd send them over to different research teams to enrich the data in various ways.
That company was very Excel heavy - which made sense, we had data entry, accountants, and other people who worked in finance.
My CTO told me a story about how one day a member of a research team asked for a new computer. The old computer worked fine, but the employee wrote a VBA script in Excel that would crunch data... and wouldn't finish until 3 days later.
This employee wanted a new computer so that he had one to use while the other one was crunching data.
We ended up taking his VBA script and putting it into our codebase.
Looks really nice.
Too bad you take businesses into hostage regarding the SSO. This is even one one the main argument in your Enterprise plan.
I know this is common behavior but I find it sad to have such an important security feature proposed only on latest plan.
I'd love to see a generative AI integration (hopefully something far better than Google's attempt). I tried to figure out how to write a python function and quickly got lost. Seems promising though.
Congrats! This looks awesome. I would love to get a sneak peek of the underlying architecture. It takes a lot of confidence to say faster than Google spreadsheets by a 1000x!
We have not tried clickhouse, but are probably comparable to DuckDB. DuckDB is also backed by Apache Arrow the same as us, but is targeting database users, whereas we are targeting spreadsheet users. They are very complementary.
Is the number crunching running fully locally via WASM? Or is it more of a websocket pushing commands thru to the backend type setup? I'm guessing the latter because of how fast the S3 import was but the former would be super interesting as well. Great demo!
Is there a way to push data into it, rather than have it pull data from data sources? I have some use cases where users want <3s latency from source data updates to the display being refreshed. For reference, I managed to get to ~10s using Google Sheets' API.
Not yet, but we could add that feature. Feel free to contact us at contact[at]rowzero.io so we can learn more about your use case. We could also maybe do some kind of webhook situation? Lots of options.
This video explains better what I'm thinking of. He has built a 16-bit computer in Excel, and where he put the different formulas for the different parts of the computer on the sheet affected how it worked (he basically had to change his design because of how Excel calculates). https://www.youtube.com/watch?v=5rg7xvTJ8SU
A better Excel sounds nice, but the problem is Excel is already on my computer and used by everyone. It's a universal format for most people in the business world. If your product is really that superior, I wish Microsoft would just buy y'all out and rewrite Excel from scratch using your product. I guess they can't do to infinite backwards capability needs as half the world prob runs off Excel spreadsheets.
The reason we launched a hosted product first is to get around the chicken and egg problem you describe. You can create a workbook and just share a link with a colleague - they don't have to install anything. If you turn on link-sharing under the workbook's "Share" menu, they don't need an account either. The cloud also provides some powerful performance advantages.
224 comments
[ 3.2 ms ] story [ 245 ms ] threadWhen I worked in AWS S3, I spent a lot of time in Excel. Even as a dev, it was the fastest way to explore data, build models, and share forecasts with business partners. My Excel usage was plagued by slow performance, poor cloud integration, and no first-class Python support. I loved the richness and responsiveness of Excel, but I had to give up too much power to get it. This felt like a false choice, so 3 years ago I started working on it.
Today we're launching Row Zero. Row Zero looks and feels like Excel and Google Sheets, but 100-1000x faster. You can easily import gigabytes of CSV, JSONL, and Parquet files or connect directly to Snowflake, Redshift, Postgres, and S3. We also support Python natively. You can call Python functions that return pandas data frames and manipulate the results directly in the spreadsheet.
Under the hood, Row Zero is a high-performance columnar engine written in Rust. Running in AWS lets us scale compute up and down and import quickly from S3 and Snowflake. When you open a workbook, we place it in the AWS region closest to you so it feels as snappy as a desktop application.
The app is built by 5 ex-principal engineers from Amazon S3, Tableau, and Airtable. We're the team that wrote the file system that powers S3.
We've been in beta for a year. Use us to refine big CSVs, build complex financial models, create dashboards, and share large data sets. We're also a killer Snowflake/Postgres client. Give us a try and let us know what you think.
Some things are literally 10000x faster because we are internally using algorithms with better asymptotic complexity than Excel, but there are a few edge cases where we are maybe only 10x faster
(but we are always working to improve that — half my job is just analyzing flame graphs and grinding out perf improvements)
I think putting that on the site would save business customers a lot of evaluation time.
Your funding slide heading right here.
His partner was a manager, not an engineer, per https://www.geekwire.com/2024/former-aws-engineers-raise-3m-...
Personally I don’t like this sort of puffery in funding slides nor announcements.
I'm Grant Slatton, founding engineer at Row Zero, and before this I designed and led the team that built S3's new filesystem, ShardStore (check out this paper https://www.cs.utexas.edu/~bornholt/papers/shardstore-sosp21...). Our other Row Zero backend engineers (Breck, Erich, Greg) were all on the team.
Our frontend guy is ex-Airtable.
Please, please, please put an “about us” page on your site. People get leery when there aren’t named humans identified as being behind a product that’s asking for production data access.
If you need a supercomputer for 30 minutes, we can get you one.
1) Signup for an account
2) Create a workbook
3) Click share and put in friend's email
4) They get an invite
5) Now they need to sign up
6) They can edit my doc
I'm not a paying customer (or even a user... I just heard of this), so take this with a grain of salt, but what I'd love to see is a super-friction-less way for me to share a doc and make it editable without others needing accounts. Cut out as many steps as possible above. Doing this can be a great tool for marketing... what's better marketing than easily collaborating on a spreadsheet on a site that my friend is already using and that already looks very similar to tools I'm familiar with?
This requirement brings a very difficult mix of challenges around security, privacy, regulatory compliance and business priorities.
As a toy / personal project it could work, but realistically this is unlikely to ever materialize in a way that you imagine.
I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it.
For example, the docs show the product wants static creds for a Postgres database or signed URL for S3 bucket instead of leveraging best-practice service-to-service identity and access management.
Maybe you support what I want, and I didn't find it at first glance.
This either ...
(a) needs to support modern dynamic or token-based authentication (e.g. Oauth2.0 client credentials grant, JWT, or for enterprises ideally CSP native IAM in Azure/GCP/AWS such as share S3 by cross account bucket permissions policy instead of signed URL, etc.), or ...
(b) allow firms to operate this themselves so the spreadsheet is run in the firm's security context, no creds are shared and data never leaves.
As you are running in AWS, providing this to run in AWS IAM context could solve it, but it's likely worth your time collaborating closely with FS firms that have solved cloud-native infosec at scale for the world's most demanding regulatory environments such as GSIFIs/GSIBs, since if you can do that, it's secure for anyone. Similar for HIPAA or FedRAMP.
If your customers can be fully best practice compliant within these regulatory regimes without having to lower their standards or get exceptions to use you, then it's above the bar for pretty much everyone.
// Full disclosure: Although using all 3 of AWS, Azure, and GCP, I was an AWS CAB member for half a decade (as principal engineers you likely know what this means), with a native-AWS preference.
>I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it.
Else this applies for us too.
We also have dedicated hosting options for our Enterprise tier.
If there's a specific data source you'd like us to support OAuth integration for, let me know, and we'll add it.
That seems like a huge privacy hole. It sounds like you're offering spreadsheet-as-a-service, where you scale up AWS spot instances based on query size.
Are you able to be “NSL-proof”?
This means, if you are served a national security letter with a gag order saying to turn over my data without telling me, can you?
If you are not NSL proof, are you able to demonstrate who from your firm can, and cannot, by technical guarantee not by policy in the “signed agreement” sense, see my data, and can I see in an audit log any time and every time any of those people do see my data?
It is possible for the answer to be that a service is NSL proof -- with asterisks, and the asterisks are very interesting to discuss.
And no, it's not about the US security apparatus for most firms, although if you take a look at AWS's security teams, you'll see there is a lot of experience exchanged, and AWS does secure the US security apparatus' data.
They're quite good at it.
with the exception of red teams, AWS isn't securing AWS from US security apparatus attack though.
Would you be ok with a new file format or do we need to save to .xlsx?
How important is Python in a desktop version? Would you need integration with conda or virtualenv?
How much do you think we should charge?
2. A lot of our sheets use VB/macros so a scripting language is pretty useful. Not sure about the other stuff.
3. No idea, around the price for an office 365 seat?
python in the app needs to be wholly self contained so whatever the backend it uses, it's separate from anything else on the system.
charge through the nose for desktop clients because of how much it costs in development and support time. people who want native clients so it's not up on a cloud somewhere for whatever reason can pay for that privilege.
I would love a performant desktop excel replacement - I miss using excel 2003 - it has been downhill ever since...
That said, I'm clearly not the target market for this product though I believe there's some degree of frustration with how poorly modern excel works with many files now which this product may address.
I would guess that making this a light-weight and performant (not electron) desktop app (ideally portable so installing it wouldn't require admin access) with substantial feature parity and compatibility with excel would be a big deal - I'd install it right away...
Currently, the only way to do this from Excel (e.g. saving a snapshot of an analyst's current dashboard that they just built) is through a macro, which then starts the (understandable) descent into Excel's External Content and Trust Center permissions hell.
We have gotten a lot of requests for write-back-to-DB (Snowflake, Postgres, etc) so will be adding first-class support for this feature soon that will use the same connection creds which are stored encrypted in KMS and are not viewable to people you share the workbook with.
Would love to chat about your use-case if you want to reach out to us at contact[at]rowzero.io
https://techcommunity.microsoft.com/t5/excel-blog/announcing...
Would like to see a more detailed comparison than the one they've got in their blog, though.
Are you compatible with excel functions?
If we're missing any formulas you need, message me at breck at rowzero.io and we'll add them (usually within 24 hours).
They are all ultimately just different UIs on top of Arrow.
They're complimentary tools. We can take data out of the spreadsheet and put it into Polars instantly (you can do this in the Python code window if you want), etc.
Regarding why not implement our spreadsheet built on top of those: spreadsheet allow for heterogenous types in columns, so that requires a lot of extra infrastructure to manage, whereas Datafusion and Polars require homogenous column types.
Your product looks great.
Would you mind helping me understand the differences between RowZero and something like Equals.com?
I'd be looking very much forward for: data validation, conditional formatting (including heatmaps) and - what gSheet doesn't offer natively, multiple choices cells via data validation or values from another column/sheet.
<s>I was surprised I couldn't way to view a spreadsheet as a DataTable, or back as a DataTable</s> (LE: found later how in documentation). And no sticky/frozen header row, ugh.
Cherry on top would be gSheets like SQL flavoured QUERY.
LE2: to add the wishlist, a potentially killer feature to/for some, dashboard type of sheet, with minimal/layout options –rows & columns blocks that can host charts & text (headings & paragraphs), with global filters – it would add a feature or two complementary to what gSheets offers. And at some point maybe, comments - per sheet or column only.
If you're open to it, email us at contact[at]rowzero.io and we would love to do a call to talk about your use case, what features you want, etc. We love doing customer calls and adding delightful features.
Working on this spreadsheet engine has been one of the most exciting, complex, and stimulating engineering experiences of my career.
Feel free to ask any technical questions about the product. We're really proud of what we've build and what's on the roadmap!
Tech stack:
Everything runs on AWS
Frontend: TypeScript + some Rust compiled to WASM, our own virtualized custom canvas magic
Backend: Rust, Apache Arrow
The biggest tech challenges... where to start.
1. As with any editor application, Undo/Redo is devilishly hard
2. A spreadsheet is modeled as a Directed Acyclic Graph where cells depend on other cells down to some root cells. There are a TON of fascinating graph theory algorithms you can bring to bear here. Some of the hardest problems I have ever worked on. My whiteboard looks like an insane person's with crazy arrows between cells and stuff.
3. Sometimes there really is no magic bullet and you just have to run benchmark, get flamegraph, chip away 3%, repeat, do that 100 times and you are very fast. Gotta grind.
For storage and orchestration we use S3 and Dynamo.
Yes exactly, we use CRDTs for multiplayer stuff.
Our frontend guy is brilliant and built a lot of awesome stuff at Airtable, but I can't speak to the craziness that is high-complexity high-performance frontend. But it's absolutely necessary to a good product too!
Can you share some of the books that can help with this? Which algorithms were used, how etc.
Thank in advance, I am using Row Zero since yesterday and loving it thoroughly.
For a project that will teach you literally everything there is to know about backend development:
1. Write a simple PUT/GET/DELETE REST API network layer, this should be a few hundred lines of code max depending on how much you choose to lean on libraries vs write it yourself
2. Then, write a simple in-memory blob store behind the PUT/GET/DELETE REST API. Just use a very simple hashmap of keys to data. You now have an in-memory S3 mock!
3. Now, rather than in-memory hashmap, start saving the files to disk. Write code that allows you to start and stop the process and recover all the data from disk. Now you have a persistent S3 mock.
4. Now, start finding the limits of this application. Write a program that calls your API with different usage patterns to load test it. Find the limits.
5. Now start optimizing. You can go as far as you want here. This optimization process was my whole career at AWS S3, and most of it at Row Zero.
6. If you want to really learn some advanced data structures and algorithms, stop using the filesystem directly, and write your own storage mechanism. Allocate 1 giant 16GB (or however large) file and store all of your blob data inside that 16GB "partition". You have to do all the serialization and retrieval etc yourself.
Your filesystem is already doing this for you when you store as files (look up how the ext4 filesystem works, inodes, pages, etc). But your filesystem is probably optimized for consumer use, not this blob-storage system use.
So you can implement your own much faster version if you want. If you want to really learn datastructures and algorithms, try to code a simple Log Structured Merge Tree. This will teach hashes, trees, bloom filters, serialization, deserialization, etc, all with high performance in mind.
I interviewed at a spreadsheet company (for a frontend role) and they asked, "how would you go about determining what cells need a border when a user clicks an individual cell, clicks a cell and selects multiple cells, clicks a cell next to an already selected cell." Fascinating problem and we talked about solutions for a little bit.
Noticed that you can't unselect a cell once it's selected? I'm on a Mac with Chrome (latest, no updates available).
Repo steps: 1. Select a few cells (⌘ + click) or an individual cell 2. Try unselecting (⌘ + click) those same cells clicked in #1 3. Cell is not unselected
Great interview question. Tons of nuance to drawing borders on adjacent cells, how to handle varying thickness, etc. Once you start looking closely, you notice the pixel differences between how this gets handled by various spreadsheeting tools.
Thanks for the report! This one's already on my list actually (selection negation & unique selection deduping) -- look for a fix soon.
One pivotal feature that is difficult to map onto 3P tools is our data table UI, which is a separate scrollable grid that floats on top of the main sheet. That, combined with the complexity of formula selection, inserting buttons into cells (header dropdowns, filter, sort), led us to decide that rolling our own solution for full control was the right choice.
I am the creator of DataGridXL (https://datagridxl.com), an Excel-like data grid component and it uses native scrolling. However, the document/sheet height/width is indeed limited by max div dimensions. Does your spreadsheet have a max?
What made you choose this tech stack? I'm especially wondering about Rust, was that something you had familiarity with before so just went with that? Did you evaluate a few different options and decided that would best fit this use-case?
(I have very minimal familiarity with Rust, I'm just wondering here.)
I'm guessing this post is going to the front of HN. If you've got some sample data, you should put it into the demo sheet ASAP. Or at the very least, provide some links to s3 files the user can manually add to test it themselves.
The biggest issue that I think I would run into in my organization is that all of the spreadsheet lovers are Excel die-hards and they refuse to even use Google Sheets, not to mention something else that isn't Excel.
But maybe they could finally be convinced to stop complaining aboutrequesting huge files with something like this...
The use-case you describe is exactly what we built it for. There are a lot of people who have data that is no longer human-scale and won't fit into Excel, but they still want to use their Excel skills.
We love Excel and spreadsheets, but when working at AWS we found we just had too much data to fit into it.
https://www.youtube.com/watch?v=VI_riscmviI&list=PLJsVF3gZDc...
Its Martin Skreli (yes that one) -- but see how fast this guy is with excel... this is what I imagine when I think of excel power users...
(But also, he does a lesson in DD on investing and doing calcs in Excel - so aside from awesome Excel input, there is good investing info here - recall this was the guy that bought a medical company and immediately raised the price 7,000% or some such (he then bought the Wu Tang Album whilst imprisoned)
I imagine many professions won't be able to use Excel in 10 years based on this trend.
Unless Microsoft invests in row zero as a "distribution partner" as it did with Mistral, you mean: Row Zero, available now on Azure.
There, I fixed it for you.
You generate 1gb of critical financial data...that most of your Excel die-hard users can't actually use because their computer can't handle it.
How does your org complete any work then?
perhaps via some more "accountant friendly" app than SQL?
That said, I suppose that's partly the goal of this product... a visual/faster alternative to SQL though I personally avoid putting big data in excel, I just (as an accountant myself) carve out subsets from SQL and then peruse it via excel to identify whatever transactions/activity I need to analyze since the web interface for the ERP is such slow steaming garbage...
I'm more in search of a better excel than an excel which can handle big data as I suspect many users will somehow, no matter how well this is built, make it slow/terrible whereas an SQL based approach could be multiple of orders of magnitude faster....
- Causal.app
- Rows.com
- Equals.com
- and at least 50 others I've found
I'm waiting for someone to create a really high performant spreadsheet engine that runs in WASM to power even more spreadsheet-y applications. The direct manipulation of spreadsheets is super underrated.
Still looking for a replacement Lotus Improv (can't justify Quantrix Financial).
There was the beginnings of an opensource implementation, Flexisheet, or see:
https://instadeq.com/blog/posts/no-code-history-lotus-improv...
We can handle 100x more data than Excel (online or desktop), Google Sheets, etc.
I suspect that people glued to M365 ecosystem are the LAST ones to consider leaving Excel online, but that's okay!
Spreadsheets are hard to do and even harder to do right, so congrats on launching—although given your backgrounds I don't think you ever lacked the manpower to let this be a technical challenge ;-)
My initial reaction:
* It does feel pretty fast
* but spreadsheets on the browser always represent an inferior UX
* the data tables / formula tables are a solid idea
* no self-hosting outside of Enterprise makes switching to this harder than it ought to be
* limiting the free plan to 3 sheets feels like a strange decision
What do you mean by this? Inferior to a standalone app? Inferior to some other design in general?
But even then, the benchmark is Excel. Nearly every Excel user is saving files to disk. Companies like to own data in a shared drive on a network. Maybe making networked drives better is another problem that needs solving, but I don't think spreadsheet applications should disregard that and just hope everyone moves to online. At a minimum you should give users a choice (which Excel/Office does, by the way)
And we still haven't talked about navigating the UI with the keyboard. Limiting power users to online-only is like telling vim users they have to use Notepad++. Sure, they can do everything they could in vim, but it's overall objectively worse
Do they actually like that? Or is that the weight of 30—no, 50—years of legacy momentum? shuffling files around is the worst part of knowledge work!
pseudo-files are the worst part of Google Docs, i want a unified graph!
And we still haven't talked about keyboard navigation!
Applications that are not based on files create their own little separate universe, or rather island, that isn’t really interoperable.
I see diverse, inhomogenous state schemas that are deeply coupled to the originating application (internal data structures serialized to disk!) and have arbitrary legacy structural constraints ("document") as well as seams between application silos
Regarding the file contents, how is that different when the data is proprietarily stored in hidden SaaS databases?
That's certainly true among a subset of users who demand Excel power features, but it is not a universal benchmark. People who more highly value collaboration might prefer Google Sheets. There are tons of users and use cases where the choice of local storage is irrelevant or even a drawback.
I agree it feels clunky to me who grew up on excel the application. I memorized a few dozen keyboard shortcuts that are all broken in the "teams collaboration browser spreadsheet" sigh.
Sharepoint would be so good if the UI was faster and more consistent. Also why is the search so impressively bad?
Attempting to import from various sources (urls and upload) and it fails:
https://i.imgur.com/YV865bw.png
It also stalls for a really long time arttempting to link to large CSV URLS... and it fails on JSON.
This 37kb CSV file took over a minute to load:
https://i.imgur.com/tHN4Wq0.png
It has ONE ROW.
I assume im holding it wrong, the local CSV has thousands of rows:
https://i.imgur.com/fujf1p5.png
---
I had to reload the session to get it to allow import, and this 37... and it took 24 seconds to import the data:
https://i.imgur.com/LnFIgL3.png
Linking to a URL and hitting import it thinks for a bit or fails....
What makes the free tier different here? Are you storing free data in a different area with many less restrictions on who has access to it? How do I know what I upload is safe from being analyzed or sold? Are you using this data to train any data models but only in the free / pro tiers that aren't SOC 2 or HIPAA compliant?
Can you please answer the question about how our data is viewed and or used internally?
> Contact US
Yeah no thanks.
I feel pretty confident saying that probably 5% of the world's economy runs on VBA macros that were started by some eager worker that was tired of doing repetitive tasks and wondered what that "Record Macro" button did. I've heard that same story personally from so many users, about how they learned to code by hitting "Record Macro", doing something and looking at the resulting code. Their macro then grows and grows and ends up powering the entire business, but becomes an unmaintainable mess.
If you add the ability to record macros and maybe a VBA -> Python cross compiler, that would probably be killer for a lot of people. Though honestly, I've seen some stuff in VBA that's probably best left alone (e.g.: a self-rewriting VBA macro).
That being said, I'm sure your biggest hurdles are going to be cultural rather than technical. Excel is just so ingrained in so many business. But I genuinely wish you best of luck and am rooting for y'all!
I think they were using file system calls with some tools to rewrite the file directly. But IIRC it's possible to do it just via the API.
This is like running into issues with non-converging iterated calculations...
I never understood two of Microsoft's owngoals:
1) The lack of a migration path from workgroup (LAN) to client-server for Access et al. So dumb. SQL Server should have become a first class citizen of Access. Or Access become a viable front-end end to SQL Server. Where swapping JET and MSSQL was a drop-in no-brainer. (Maybe that happened later...)
2) Not unifying tabular data. And then make Excel and Access "modalities" (?) for accessing that data. Lotus' Symphony (successor to 1-2-3) was so awesome; hybrid database and spreadsheet. aka The Correct Answer™. And Symphony was on DOS! (Lotus' Improv was even cooler. I wish I knew why it didn't succeed.)
I guess all this ML data pipeline Parquet NumPy stuff finally separated tabular data from how it's used. Yay.
I haven't used the Microsoft stack in anger since late '90s, when Java emerged, so maybe the .Net/CLR reboot mooted my complaints.
I never had the chance to use Borland's tools (Paradox, QuattroPro) in anger, so don't know if they did any better.
We'd collect data sets from various sources (like public filings from the SEC) and the we'd send them over to different research teams to enrich the data in various ways.
That company was very Excel heavy - which made sense, we had data entry, accountants, and other people who worked in finance.
My CTO told me a story about how one day a member of a research team asked for a new computer. The old computer worked fine, but the employee wrote a VBA script in Excel that would crunch data... and wouldn't finish until 3 days later.
This employee wanted a new computer so that he had one to use while the other one was crunching data.
We ended up taking his VBA script and putting it into our codebase.
Hope this trend will end soon.
Copilot for formulas, auto-write python, etc, it'll all land soon!
How does your engine handle calc execution order?