守正出奇,穿越周期 - Bytebase 的 2023
产品迭代
-
2023 年共发布了 25 个版本。这个数字和 2022 年一样,除开春节和一次全员疫情,做到了两周一次的更新。
-
版本号从 1.11.0 升级到了 2.13.0。其中在 5 月份,我们发布了 Bytebase 2.0 版,明确了做 Database DevOps 的产品主张。
-
PR 数超过 10000,成为了 GitHub 上最繁忙的开源项目之一。
-
GitHub Star 数也从 4.7 k 增加到 8.7 k,不仅继续保持同领域内最快的增速,而且还先后超越了国外的 Flyway 和国内的 Yearning,成为了同领域内,全球 Star 最多的开源项目。
企业级,可依赖
今年 Bytebase 成为了唯一被 CNCF Landscape 和 Platform Engineering (平台工程组织) 同时收录的数据库管理工具。
目前 Bytebase 已经支持市面上 17 种主流数据库系统。提供了一套覆盖变更,查询,安全,治理的数据库开发全生命周期的解决方案。
今年 Bytebase 全面增强了企业级功能,SSO,多因素认证,动态脱敏,批量变更,自定义审批流,审计日志等。并且还通过开放 API 的方式让 Bytebase 能被集成到了企业已有的研发平台中。
旧雨新知
Bytebase 在 2022 年年中开始商业化,今年则是全面商业化的第一年。我们完成了所有老客户的续约,并且在国内又收获了电信,制造业,造车新势力等行业的标杆。同时我们还把产品卖到了全球,北美,欧洲,东南亚,中东,非洲也都有了我们的客户。
良师益友
作为一款面向开发者和 DBA 的数据库工具,Bytebase 今年也积极和上下游数据库和开发者工具建立合作关系,先后成为了 PingCAP, Snowflake, GitHub, GitLab 的全球技术合作伙伴。
受邀在 OceanBase 的年度开发者大会进行了专题分享,并且基于一同服务的客户案例,推出了「数据库变更全生命周期管理」的联合解决方案。
此外我们还支持了 RisingWave, StarRocks 这些冉冉升起的数据库新星。
守正出奇,穿越周期
不可否认,中国的企业服务正在经历低谷,面向 toB 市场的 Bytebase 自然也是受到了冲击。2023 以及即将迎来的 2024,我们依旧会开拓并且专注于「数据库开发」这一个工作流。当年 Bytebase 最早推出的 GitOps 方案现在已经出现在了 Snowflake 的产品中。
今年我们继续在产品上创新,比如第一次在数据库工具里引入了分支工作流 (Branching)。
总之,Bytebase 既要满足客户的需求,又要交付出一个面向未来的方案。
最后感谢我们所有的企业客户,社区用户,感谢你们信任一家起步不到三年的初创公司。大家有时也会操心公司的命运(代码是完全开源的,结构清晰,部署简单,如果公司倒闭了,就可以任意使用/二开)。感谢大家的关心,我们的现金流即将转正,届时等我们的好消息吧。
好啦,明年再见 👋
💡 更多资讯,请关注 Bytebase 公号:Bytebase

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
英特尔AMX助力阿里云提升推荐模型性能
背景 推荐系统在电商、短视频、新闻、广告等行业都有着广泛的应用。推荐系统能够比较准确理解终端用户的兴趣,提升终端用户的浏览体验。典型的工业界推荐系统一般采用多阶段漏斗的方式,通常包括召回、粗排、精排、重排等阶段,每个阶段要处理的商品数量是依次递减的,而对应的模型的参数量和计算复杂度通常是依次递增的。随着深度学习的发展,现在主流的推荐系统都是用深度学习模型来预估用户对于不同商品的偏好。深度学习大幅度提升了模型预估的准确度,并且能够支持多任务多场景的联合建模。但随之带来的问题是模型参数量和计算复杂度的大幅度增加,这给模型训练和在线推理服务都带来了巨大的挑战。为了提升模型的准确度,推荐模型通常需要在千亿规模的样本和特征上进行训练。即便采用分布式训练,训练一个推荐排序模型也要持续数天的时间。这给算法工程师探索和优化模型结构带来了巨大的压力。在线推理服务通常需要在有限的时间内返回结果(< 500ms),而现代推荐模型的巨大参数量和复杂的模型结构需要的计算量通常难以满足这样要求。 为了解决这些挑战,帮助用户更好的落地深度学习推荐算法,阿里云PAI团队研发了PAI-REC全链路解决方案,帮助用...
- 下一篇
我在阿里做开发的高效打工技巧总结
前言 如果您的工作中完全不需要自己写PRD 、技术方案、测试用例,那么这篇文章除了会浪费您宝贵的15分钟之外,别无益处,可以绕行了。 背景 很多新入职的工友反馈,大家现在除了编码之外,在厂子里还有很多七七八八的杂活才是工作耗时的大头,比如有些项目里面,沟通&对接相关的工作占比甚至大于70%,实际写代码&自测也就一两天,前面那些细碎的内容,也不方便录入工时,非常苦恼。出于对工友的爱和保护,鄙人决定在这里分享一些打工的技巧,希望能提供一些微不足道的小帮助。 如何高效开会 作为会议发起人 首先,作为会议发起人希望大家能自觉做到如下几点: 提前准备文档 提前准备好会议文档,比如技术方案评审,在你评审之前,至少要写好了完整的技术文档,并且提前私下里和参会的上下游开发勾兑过协议,并且在开会前,把文档贴在日程里面。最讨厌都做方案评审了,上下游都还在抓瞎,最后留下来一大堆action“会后再对”,一场会议出现超过3个“会后再对”就一定有严重的信息gap。所有的评审类型日程,都不应该发展成讨论会。为了防止有些眼神不好的工友不知道贴在哪里,我贴心做了大量截图,大家可以贴在日程描述,或者...
相关文章
文章评论
共有0条评论来说两句吧...