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.
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.
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.
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.
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
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.
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.
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!
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.
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...
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.
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.
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.
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
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!
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.
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.
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
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.
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
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.
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.
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
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.
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?
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.
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.
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.
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....
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.
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.)
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.
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?
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.
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.
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 would be a heck of a lot cooler if it was a local-first desktop application. It's still cool mind you, but it could have been a heck of a lot _more_ cool.
We have the capability to run it as a desktop app. How much do you think we should charge for it, and how do you think we should do support, feature additions, etc? We are open to the idea.
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.
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.
I could import matplotlib but I couldn't work out how to display the output. I guess that this library is supported otherwise I wouldn't be able to import it. How do I display it's output. This is the function I'm trying to run:
I'm an Excel power(max?)(ultra!?) user and the only thing I want from an alternative to microsoft word on windows is a drop in replacement to their alt shortcuts. Those are the air that I breathe when using Excel and fast isn't fast if you're working slow.
Row Zero frontend dev here. Totally understand where you're coming from; we've heard this request from others and are interested in exploring a seamless solution for `alt` reliant power users like yourself.
Drop me an email if you'd be interested in user-testing a solution! billy[at]rowzero.io
The main win from writing our own custom parser is writing directly into the final in-memory format from the parse stream without any intermediate allocations or data movement.
Awesome project! Adding it to my list of things we may plug into in the future.
Out of curiosity, do you support/have plans to support the broader set of Excel shortcuts that reference the ribbon? (Alt + <Key Sequence> shortcuts). Lots of excel power users more or less exclusively use the keyboard to navigate, and so have muscle memory for almost everything they do, including more niche operations (Insert Line Chart = Alt N N 1, or Change Column Width = Alt H O W).
Will be a very hard sell to banks/other financial services corps if you can't match that aspect of excel. (They will probably also want local files and a native app).
Good question - we've heard this feedback before and have some ideas for how to bake alt-shortcuts into the app for the muscle memory crowd. So, not yet, but its very much on our radar.
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.
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.
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!
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.
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!
Quick bug report: I set A0 and A1 to 1, then set A2 =SUM(A0:A1)+A0+A1. As expected, A2 evaluated to 4. Then I right-clicked on the 1 row header and inserted 1 row above.
Expected: A3 should become =SUM(A0:A2)+A0+A2 and evaluate to 4
Actual: A3 becomes =SUM(A0:A1)+A0+A2 and remains 4 until it is edited, at which point it evaluates to 3.
Didn't know who I was talking to, looked you up now, amazing ;)
Thanks a lot for the bug report. We actually used to implement the range-extension logic in Excel/Sheets but removed it during a cut-paste refactor due to the complexity (I'm sure you know...) and resolved to add it back when someone asked for it.
I actually found edge cases where Sheets and Excel don't do range extension logic the same way.
So we don't do the range extension for now, but the 4 not getting recomputed to 3 is definitely a bug, will fix!
We didn't know about this formula-paste-to-range functionality, we will add it in the next few days as we grind down this post-launch backlog. Let us know any other stuff we are missing please!
In the mean time you can still paste the formula to the top cell then drag it down or ctrl+D as a workaround, but we want to support the full experience, so check back in a few days and it should be there :)
I've been the excel/vba resource at various consulting firms for 20+ years...
I strongly recommend you enlist some people like me to kick the tires on your product before a more wide roll-out
among other things, I'd make an effort to implement as many standard excel functions as possible
--> I would LOVE a highly performant version of google sheets (though ideally as a desktop style app) so I can use keyboard shortcuts among other reasons
--> one thing I like about google sheets that you don't have is that it has excel style short-cuts like alt+d+f+f for autofilter... (though I really only use google sheets as a grocery list so I can walk through my house and do an inventory using my phone)
We have a super fast iteration cycle, so most times a user asks us for a feature parity thing like this, we can ship it within 24 hours. This particular one might be slow for us, a few days :)
If we waited until we had full Excel parity, we would never ship. Google Sheets has been around for 17 years and still doesn't have full Excel parity on features or functions, and that's with dozens of engineers working on it full time.
Luckily now that we are launched we have a bunch of very knowledgable people like you requesting all these features, and this gives us a really good signal for prioritization.
E.g. a bunch of other people also requested the alt-shortcuts, so they are pretty high priority
Highest priority are the bugs like jkaptur pointed out above, and some other people had some crazy CSV files that we couldn't parse. So I'll fix those today and get to the copy-paste-formula-to-range thing in the next day or two. Alt shortcuts is very high on our frontend guy's list.
I wish you luck, I can definitely appreciate the difficulty in trying to achieving some degree of excel feature parity
I had come across this copy to more than one cell issue when I was curious to see the performance myself in making some random numbers and doing some look-ups based on those results which I couldn't do en masse due to this limitation
a few other things to think about implementing
(1) some more formatting/font/point size options
(2) customizable number formatting like excel
(3) functions like hlookup, edate, perhaps even array function like functionality (i.e., a relatively powerful and open ended underused feature in excel due to a combination of difficulty in understanding as well as being very slow calculation-wise)
(4) some minimal vector drawing abilities
(5) it doesn't bother me and it's part of your marketing but starting with "0" may confuse some people (and would break excel compatibility) since excel doesn't do that (though I appreciate indices/etc. do that in "real" programming)
(6) filtering data doesn't include a "contain" or "does not contain" option
(7) perhaps some limited ability to customize the interface and have user defined keyboard shortcuts triggering formatting/etc. type macros/python
(8) some sort of print/formatting to yield output to pdf
1. Our frontend guy has been dreading this but it is high on the list nonetheless :)
2. Somewhat lower down the list but we have heard this before too
3. I have array functionality on a branch, still ironing out some rough edges, might be a month or two before we land it for real. We can add those builtins hlookup & edate very quickly.
4. We haven't heard anyone request vector drawing before. Can you elaborate on the use case? Sounds interesting.
5. Re: Row 0, we have funnily heard a lot of Excel people always wanted it, because they tend to have headers at the top, and it always bothered them referring to their data starting at A2 instead of A1. It's not a compatibility issue for import from Excel, because we just import all the data starting at A1. It can be a problem for export to Excel (which we don't have yet, but will), but we will just shift everything down by 1 row as if you had done a giant cut-paste.
6. For string types we have "contains" but we don't have "does not contain", will add it. Excel allows you to do "contains" on number types too which we thought nobody actually wanted, but if you do want it, we can add it. There are some performance implications to this because it means you have to convert numbers to strings to do the check.
7. More customization is probably farther down the line when we grow more.
8. Yes, right now we can only output to CSV. We have had some people talk about how they want to output to Powerpoint slides, PDF, etc. This is definitely on our radar.
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.
We will add a little tasteful AI stuff later, but it's not the highest priority. Top priority is big data and fast data. AI is relatively easy to layer on later.
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!
For people who want to process their XLSX/CSV files locally and want some easy to use ETL tool, maybe take a look Tablesmith: https://tablesmith.io/, it's free to use.
This may be way off course but I’m currently looking for a QuickBooks replacement with many of the features you describe. Is building a QB replacement possible within your app, if we can bring our own financial data?
I don't know enough about QuickBooks to say we can replace it. But we do have enterprise accounting teams using us to pivot millions of rows of general ledger data. So if you're looking to (e.g.) create summaries of categorized expenses, we're great for that.
Would love to talk further — if you email me at the address in my profile, I’ll get the current wishlist from our accounting dept on Monday. FWIW accounting needs are similar across all talent agency workflows and nobody’s happy, so there’s an undeserved market here for sure.
Never understood spreadsheets. Why would you assume data fits in a 2d-array? And why put heterogenous data in that 2d-array in blocks at different x,y offsets?
We have native dataframe support that encourages homogenous types, but we also want to meet Excel users where they are! Probably half the world's economy runs on Excel, it's the world's most popular programming language :)
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
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.
This use case is where we shine. Sheets is a great tool, but its performance is limited by your browser's memory, whereas Row Zero compute is happening in the cloud. Give it a try and let us know what you think!
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.
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.